/* ═══════════════════════════════════════════════════════════════════════════
   v733254 — SCROLL TRAVADO NO ANDROID.

   Relato do dono do @distritofantasma. Medido no perfil dele, que tem DOIS
   produtos: 13 elementos com `backdrop-filter: blur()` (4 visíveis), 26
   elementos `position: fixed` e 55 com `box-shadow`.

   `backdrop-filter` é o mais caro que existe numa rolagem: a cada quadro a
   GPU precisa re-amostrar tudo que está ATRÁS do elemento e borrar de novo.
   No iPhone isso passa despercebido; num Android mediano é exatamente o
   engasgo que ele descreve. E o blur não some quando o elemento sai de vista:
   enquanto estiver no fluxo, ele custa.

   Duas medidas, nesta ordem de agressividade:

   1. ENQUANTO ROLA, todo mundo perde o blur e as sombras pesadas. A pessoa
      está olhando o conteúdo passar — ninguém repara no vidro fosco a 60
      quadros por segundo. Volta 140 ms depois que a rolagem para.

   2. EM APARELHO FRACO (≤4 núcleos ou ≤4 GB), o blur não volta nunca: fica o
      fundo sólido equivalente. Vidro fosco bonito que engasga é pior que
      fundo chapado que desliza.

   O fundo sólido é obrigatório junto: tirar só o blur deixaria o elemento
   transparente e o texto ilegível sobre a foto.
   ═══════════════════════════════════════════════════════════════════════════ */
/* v733255 — `html.classe *` PERDIA a disputa. Os elementos de vidro declaram
   o blur em regras como `html body .idlink-footer-store-v73407{...!important}`,
   que tem especificidade maior que a minha — e entre dois `!important` vence o
   mais específico, não o que vem depois. Resultado medido: o fundo sólido
   entrava (essa regra era específica) e o blur continuava lá, que era
   justamente o caro. Agora entro com `html.classe body *`, acima de qualquer
   uma delas. */
/* ═══════════════════════════════════════════════════════════════════════════
   v733831b — 🔴 ESTA MÁQUINA NÃO FAZIA NADA NO CELULAR, SÓ A PISCADA.

   A ideia da v733254 era tirar o desfoque de vidro enquanto a página rola e
   devolver depois. Só que em telas até 640 px o `gates/profile.php:7515` já
   mata `backdrop-filter` de TUDO, o tempo inteiro. Medido: **0 elementos**
   mudam de `backdrop-filter` quando a classe entra ou sai — não há blur nenhum
   para tirar no celular.

   O que sobrava era só o custo. A cada virada da classe, medido na rolagem:
     · 3.169 de 3.199 elementos trocam `transition` (all ↔ none)
     · 59 elementos perdem e recuperam `box-shadow`
     · 8 barras fixas trocam o fundo para sólido e voltam
   E como o `transition` volta junto, as barras **animam** o fundo de volta em
   160 ms: é exatamente o fundo piscando que o José vê.

   Pior: a classe vira e desvira DENTRO do mesmo gesto. Os dois temporizadores
   (140 ms aqui, 160 ms no gates) são mais curtos que a pausa natural entre
   duas rajadas de dedo — medi 3 ciclos completos desliga/religa numa rolagem
   de 4 segundos. Três piscadas por rolagem.

   No desktop as regras continuam: lá o blur existe e a troca compra frame.
   ═══════════════════════════════════════════════════════════════════════════ */
/* v733896 — sem `@media`: o `backdrop-filter` é o custo real e removê-lo
   durante a rolagem vale em qualquer largura. O que eu tinha feito na v733831b
   — trancar tudo acima de 641 px — deixou o tablet deitado justamente com o
   comportamento antigo. A trava certa não é o tamanho da tela: é não apagar o
   que não custa (a sombra) e não virar a chave no meio do gesto (600 ms). */
html.idlk-rolando-v733254 body *,
html.idlk-rolando-v733254 body,
html.idlk-fraco-v733254 body *,
html.idlk-fraco-v733254 body{
  backdrop-filter:none!important;
  -webkit-backdrop-filter:none!important;
}
/* ═══════════════════════════════════════════════════════════════════════════
   v733896 — 🔴 A SOMBRA QUE PISCA É ESTA LINHA, E ELA NÃO COMPRA NADA.

   José, depois da primeira correção: "conforme você scrolla o perfil web, a
   sombra atrás e a foto dos produtos pisca. Aparenta mais quando o tablet tá
   deitado, mas mobile também acontece."

   Duas coisas ficaram de pé na v733831b e eu não vi:

   1. Eu confinei a máquina de rolagem a `min-width:641px` achando que isso era
      "só desktop". **Tablet deitado tem 1024 px** — ou seja, exatamente onde
      ele mais reclama, a máquina continuou ligada. Consertar pelo breakpoint
      foi consertar o sintoma no lugar errado.

   2. `body *{box-shadow:none}` apaga a sombra de ~59 elementos quando a
      rolagem começa e devolve quando ela para. Como o `transition` também sai
      e volta, a devolução é ANIMADA. Isso não é um efeito colateral da
      otimização: isso É a piscada que ele está vendo.

   E o que essa linha economiza? Sombra é barata; o caro era o `backdrop-filter`
   — esse continua sendo removido, que é o ponto legítimo da v733254. Apagar
   sombra junto foi um exagero que custou a aparência e não devolveu frame.
   ═══════════════════════════════════════════════════════════════════════════ */
/* (a regra de box-shadow saiu — era ela que piscava) */
/* sem o blur, o vidro vira fundo sólido — senão o texto fica ilegível */
html.idlk-rolando-v733254 .idlink-footer-store-v73407,
html.idlk-rolando-v733254 .idlink-profile-brand-cta,
html.idlk-rolando-v733254 .idlink-profile-language-trigger,
html.idlk-rolando-v733254 #idlinkShopSearchDockV64421157,
html.idlk-fraco-v733254 .idlink-footer-store-v73407,
html.idlk-fraco-v733254 .idlink-profile-brand-cta,
html.idlk-fraco-v733254 .idlink-profile-language-trigger,
html.idlk-fraco-v733254 #idlinkShopSearchDockV64421157{
  background-color:rgba(12,12,14,.92)!important;
}
/* v733896 — fim do bloco (o @media saiu) */
/* o que está fora da tela não precisa ser desenhado */
html.idlk-fraco-v733254 #bio-shop-panel > *{
  content-visibility:auto;
  contain-intrinsic-size:auto 240px;
}