/* =====================================================================
 *  CORREÇÕES DE VISUALIZAÇÃO MOBILE — SacamotoFlow
 * =====================================================================
 *  Carregado DEPOIS do CSS do Tailwind compilado, para sobrepor sem
 *  precisar tocar no bundle React (que não tem código-fonte disponível).
 *
 *  Regra de ouro deste arquivo: só usa seletores que sobrevivem a um
 *  rebuild do frontend — classes utilitárias do Tailwind (estáveis por
 *  definição) e atributos ARIA do dnd-kit. Nada de nomes gerados.
 * ===================================================================== */

/* ---------------------------------------------------------------------
 * 1. Zoom automático do iOS ao focar um campo
 *
 * O Safari no iPhone dá zoom sozinho sempre que o usuário toca num campo
 * com fonte menor que 16px — e a aplicação usa .text-sm (14px) em quase
 * todos os inputs. O resultado é a tela "pulando" a cada toque, e o
 * usuário tendo que pinçar de volta.
 *
 * 16px é o mínimo exato que impede esse comportamento.
 * ------------------------------------------------------------------- */
@media (max-width: 767px) {
  input[type="text"],
  input[type="email"],
  input[type="password"],
  input[type="number"],
  input[type="search"],
  input[type="tel"],
  input[type="url"],
  input[type="date"],
  input[type="datetime-local"],
  input[type="time"],
  input:not([type]),
  select,
  textarea {
    font-size: 16px !important;
  }
}

/* ---------------------------------------------------------------------
 * 2. Grades de 2 colunas em telas estreitas
 *
 * `grid-cols-2` sem prefixo responsivo vale em qualquer largura, então
 * num celular de 360–390px os campos ficam espremidos em duas colunas.
 *
 * Só afeta a classe sem prefixo: as variantes (md:grid-cols-2 etc.) são
 * compiladas dentro de @media (min-width:…), que não casa aqui.
 * ------------------------------------------------------------------- */
/* (substituído pelo item 10, no fim deste arquivo — ponto de corte 767px) */

/* ---------------------------------------------------------------------
 * 3. Nada pode vazar horizontalmente para fora da tela
 *
 * Sem isto, um único elemento largo demais empurra a página inteira e
 * cria aquele deslocamento lateral em que o conteúdo "foge" e não volta.
 * ------------------------------------------------------------------- */
@media (max-width: 767px) {
  html, body { overflow-x: hidden; max-width: 100vw; }

  /* Imagens e mídia nunca estouram o container */
  img, svg, video, canvas { max-width: 100%; height: auto; }

  /* Palavras/códigos longos quebram em vez de alargar o pai.
   *
   * ⚠️ Escopo reduzido na versão 1.5. A 1.3 aplicava `overflow-wrap: anywhere`
   * também em span/p/h1-h3, e isso tinha um efeito colateral sério: `anywhere`
   * reduz a LARGURA MÍNIMA DE CONTEÚDO do elemento, então um item flex podia
   * encolher abaixo da largura da palavra e estilhaçar o texto letra a letra
   * ("PED-2026-005" virando "PED-/202/6-/005"). `break-word` quebra palavras
   * longas do mesmo jeito, mas NÃO mexe no cálculo de largura mínima. */
  td, th { overflow-wrap: break-word; }
  .break-anywhere-mobile { overflow-wrap: anywhere; }
}

/* ---------------------------------------------------------------------
 * 4. Áreas roláveis na horizontal — rolagem suave e pista visual
 *
 * As tabelas largas do sistema já ficam dentro de .overflow-x-auto, mas
 * nada indica que elas rolam: o usuário vê a tabela cortada e conclui
 * que o sistema "não cabe na tela". O degradê na borda direita, que some
 * ao chegar no fim, resolve isso sem ocupar espaço.
 * ------------------------------------------------------------------- */
.overflow-x-auto {
  -webkit-overflow-scrolling: touch;   /* inércia no iOS */
  scrollbar-width: thin;
}

/* Barra de rolagem visível e fina (WebKit) — sem ela o desktop também
   fica sem pista de que há mais conteúdo. */
.overflow-x-auto::-webkit-scrollbar { height: 8px; }
.overflow-x-auto::-webkit-scrollbar-track { background: rgba(0,0,0,.04); border-radius: 4px; }
.overflow-x-auto::-webkit-scrollbar-thumb { background: rgba(0,0,0,.22); border-radius: 4px; }
.overflow-x-auto::-webkit-scrollbar-thumb:hover { background: rgba(0,0,0,.35); }

/* Wrapper adicionado pelo script de mobile (ver index.html) */
.sf-pan-wrap { position: relative; }

.sf-pan-wrap::after {
  content: "";
  position: absolute;
  top: 0; right: 0; bottom: 0;
  width: 28px;
  pointer-events: none;
  background: linear-gradient(to right, rgba(255,255,255,0), rgba(255,255,255,.92));
  opacity: 1;
  transition: opacity .18s ease;
}
.sf-pan-wrap[data-sf-fim="1"]::after { opacity: 0; }

/* Dica textual, mostrada uma vez por área rolável */
.sf-dica-rolagem {
  display: inline-flex; align-items: center; gap: 5px;
  font-size: 11px; line-height: 1; color: #64748b;
  background: #f1f5f9; border: 1px solid #e2e8f0;
  padding: 4px 8px; border-radius: 999px;
  margin: 0 0 6px; user-select: none;
}

/* Cursor de "agarrar" onde o arraste com mouse está ativo */
.sf-pan-ativo { cursor: grab; }
.sf-pan-ativo.sf-arrastando { cursor: grabbing; user-select: none; }

/* ---------------------------------------------------------------------
 * 5. Arrastar cards de tarefa no celular
 *
 * O dnd-kit marca todo elemento arrastável com aria-roledescription.
 * `touch-action: manipulation` remove o atraso de ~300ms do duplo-toque
 * sem bloquear a rolagem da página — combinado com a ativação por
 * toque-e-segure (ver o patch no bundle, versão 1.3), é o que faz o
 * arraste funcionar no celular sem impedir de rolar a lista.
 * ------------------------------------------------------------------- */
[aria-roledescription="draggable"],
[aria-roledescription="sortable"] {
  touch-action: manipulation;
  -webkit-tap-highlight-color: transparent;
}

/* ⚠️ NÃO adianta trocar `touch-action` depois que o gesto começou.
 *
 * O navegador consulta essa propriedade UMA vez, no instante do toque. Como o
 * arraste só é ativado 200ms depois, qualquer `touch-action: none` aplicado
 * nesse momento chega tarde: o navegador já decidiu que o gesto pode rolar.
 * Era essa a causa de o arraste cancelar ao mudar de coluna (versão 1.8).
 *
 * A regra que existia aqui foi removida por ser inócua. Quem segura a rolagem
 * durante o arraste é o `preventDefault()` do touchmove, em index.html. */

/* Enquanto arrasta um card.
 *
 * ⚠️ `overflow: hidden` foi REMOVIDO na versão 1.8: com a página rolada, ele
 * podia provocar um salto de layout no meio do arraste. Quem segura a rolagem
 * agora é o `preventDefault()` do touchmove (ver index.html) — que, ao
 * contrário do `touch-action`, funciona no meio do gesto. */
body.sf-arrastando-card {
  overscroll-behavior: none;
}

/* Retorno visual do toque-e-segure: o card "acorda" antes de soltar */
@media (pointer: coarse) {
  [aria-roledescription="draggable"],
  [aria-roledescription="sortable"] {
    transition: transform .12s ease, box-shadow .12s ease;
  }
  [aria-roledescription="draggable"]:active,
  [aria-roledescription="sortable"]:active {
    transform: scale(1.02);
    box-shadow: 0 6px 16px rgba(0,0,0,.14);
  }
}

/* ---------------------------------------------------------------------
 * 6. Alvos de toque
 *
 * Botões de ícone com 24–28px são difíceis de acertar com o dedo. O
 * mínimo recomendado é 44px; 40px é o meio-termo que não desmonta o
 * layout compacto das listas.
 * ------------------------------------------------------------------- */
@media (pointer: coarse) {
  button, [role="button"], a.btn, .cursor-pointer > svg {
    min-height: 36px;
  }
  /* Botões que só têm ícone: garante área clicável quadrada */
  button.p-1, button.p-1\.5, button.p-2 {
    min-width: 36px;
    display: inline-flex;
    align-items: center;
    justify-content: center;
  }
}

/* ---------------------------------------------------------------------
 * 7. Modais e diálogos
 *
 * Vários modais usam altura livre: num celular deitado, ou com teclado
 * aberto, o rodapé (onde ficam Salvar/Cancelar) sai da tela sem jeito de
 * alcançar. Limitar a altura e rolar por dentro resolve.
 * ------------------------------------------------------------------- */
@media (max-width: 767px) {
  .fixed.inset-0 > .relative,
  .fixed.inset-0 > div:not(.absolute) {
    max-height: 92vh;
    overflow-y: auto;
    -webkit-overflow-scrolling: touch;
  }
}

/* ---------------------------------------------------------------------
 * 8. Respeito à área segura (notch / barra de gestos)
 * ------------------------------------------------------------------- */
@supports (padding: max(0px)) {
  @media (max-width: 767px) {
    body { padding-bottom: env(safe-area-inset-bottom); }
  }
}

/* ---------------------------------------------------------------------
 * 9. Pedidos com o mesmo comportamento de Retirada/Devolução
 *
 * As duas telas mostram uma lista de itens em grade de colunas fixas, mas
 * só Retiradas envolve a grade num container rolável:
 *
 *   Retiradas → <div class="scroll-x -mx-3 px-3">
 *                 <div class="min-w-[480px]">
 *                   <div class="grid grid-cols-[90px,1fr,80px,auto,auto]">
 *
 *   Pedidos   → <div class="grid grid-cols-[1fr,80px,auto,auto]">
 *               (sem wrapper e sem largura mínima)
 *
 * Sem o wrapper, no celular a coluna do produto (1fr) colapsa e os botões
 * se amontoam — é o "formato bagunçado". Como não dá para inserir um
 * elemento no meio do que o React renderiza sem risco de atrapalhar a
 * reconciliação, a mesma coisa é feita só com CSS: o container que abriga
 * a grade passa a rolar, e as linhas ganham largura mínima.
 *
 * 420px = 4 colunas (Pedidos), contra 480px de Retiradas, que tem 5.
 * ------------------------------------------------------------------- */
.border.rounded-xl:has(> .grid-cols-\[1fr\,80px\,auto\,auto\]) {
  overflow-x: auto;
  -webkit-overflow-scrolling: touch;
}

.grid-cols-\[1fr\,80px\,auto\,auto\] {
  min-width: 420px;
}

/* Reserva para navegadores sem :has() — o container do modal de itens
   ganha rolagem de qualquer forma. Não é tão preciso, mas não quebra nada:
   containers que já cabem na tela simplesmente não rolam. */
@supports not selector(:has(*)) {
  @media (max-width: 767px) {
    .border.rounded-xl.p-3.space-y-2 {
      overflow-x: auto;
      -webkit-overflow-scrolling: touch;
    }
  }
}

/* ---------------------------------------------------------------------
 * 10. Grades de 2 colunas seguem o mesmo ponto de corte do resto do app
 *
 * A aplicação usa `md:grid-cols-2` (2 colunas a partir de 768px) em quase
 * todo lugar — mas em 10 pontos escapou um `grid-cols-2` sem prefixo, que
 * vale em qualquer largura. Entre 480 e 767px isso fazia Pedidos mostrar
 * duas colunas enquanto Retiradas mostrava uma, na mesma tela.
 *
 * Alinhar ao ponto de corte `md` do próprio app deixa as telas coerentes.
 * (Substitui o limite de 480px que a versão 1.3 usava.)
 * ------------------------------------------------------------------- */
@media (max-width: 767px) {
  .grid-cols-2,
  .grid-cols-3,
  .grid-cols-4 {
    grid-template-columns: minmax(0, 1fr) !important;
  }
}

/* ---------------------------------------------------------------------
 * 11. A classe própria .scroll-x recebe o mesmo tratamento do Tailwind
 *
 * O app define `.scroll-x { overflow-x:auto }` e a usa em Retiradas. O
 * script de mobile procura por `.overflow-x-auto`, então sem isto aquela
 * área ficaria sem a pista visual de rolagem que todas as outras têm.
 * ------------------------------------------------------------------- */
.scroll-x {
  scrollbar-width: thin;
}
.scroll-x::-webkit-scrollbar { height: 8px; }
.scroll-x::-webkit-scrollbar-track { background: rgba(0,0,0,.04); border-radius: 4px; }
.scroll-x::-webkit-scrollbar-thumb { background: rgba(0,0,0,.22); border-radius: 4px; }

/* ---------------------------------------------------------------------
 * 12. Cards de listagem: Pedidos ganha o layout mobile de Retiradas
 *
 * As duas telas usam o mesmo cabeçalho de card — ícone quadrado, bloco de
 * texto (código + badges + metadados) e área de ações. Mas só Retiradas
 * foi escrita de forma responsiva:
 *
 *   Retiradas  <div class="flex flex-col md:flex-row md:items-center
 *                          md:justify-between gap-3">      ← empilha no celular
 *                <div class="flex items-start gap-3 min-w-0">
 *                  <div class="p-2 rounded-lg flex-shrink-0">ícone</div>
 *                  <div class="min-w-0 flex-1">
 *                    <div class="flex items-center gap-2 flex-wrap">
 *
 *   Pedidos    <div class="flex items-center justify-between">  ← sempre lado a lado
 *                <div class="flex items-center gap-3">
 *                  <div class="p-2 rounded-lg">ícone</div>
 *                  <div>
 *                    <div class="flex items-center gap-2">
 *
 * Faltam cinco coisas em Pedidos: empilhar no celular, `min-w-0` no bloco de
 * info, `flex-shrink-0` no ícone, `min-w-0 flex-1` na coluna de texto e
 * `flex-wrap` na linha dos badges.
 *
 * Sem `flex-wrap`, a linha de badges não pode quebrar: o flex comprime cada
 * filho até o texto estilhaçar na vertical — é o "En/tr/ad/a" e o
 * "Em/an/áli/se" das capturas. E sem empilhar, os botões Aceitar/Recusar
 * disputam a largura com o código do pedido.
 *
 * As regras abaixo reproduzem as cinco. Elas são idempotentes em Retiradas
 * (que já tem tudo isso), então valem para os dois — e para qualquer outro
 * card que siga o mesmo padrão.
 * ------------------------------------------------------------------- */
@media (max-width: 767px) {

  /* a) O cabeçalho empilha: informação em cima, ações embaixo */
  .shadow-card > .flex.justify-between:has(> .flex.gap-3 > .p-2.rounded-lg) {
    flex-direction: column;
    align-items: stretch;
    gap: 0.75rem;
  }

  /* b) O bloco de informação pode encolher (senão nada trunca) */
  .shadow-card > .flex.justify-between > .flex.gap-3:has(> .p-2.rounded-lg) {
    min-width: 0;
    align-items: flex-start;
  }

  /* c) O ícone nunca encolhe */
  .shadow-card .flex.gap-3 > .p-2.rounded-lg {
    flex-shrink: 0;
  }

  /* d) A coluna de texto ocupa o resto e pode truncar */
  .shadow-card .flex.gap-3 > .p-2.rounded-lg + div {
    min-width: 0;
    flex: 1 1 0%;
  }

  /* e) Código e badges quebram em nova linha em vez de comprimir */
  .shadow-card .flex.gap-3 > .p-2.rounded-lg + div > .flex.items-center.gap-2 {
    flex-wrap: wrap;
  }

  /* f) A área de ações fica alinhada à esquerda quando vai para baixo,
        acompanhando o comportamento de Retiradas */
  .shadow-card > .flex.justify-between:has(> .flex.gap-3 > .p-2.rounded-lg) > :last-child {
    flex-wrap: wrap;
  }
}

/* Reserva para navegadores sem :has(): aplica só o que não depende dele.
   Resolve o estilhaçamento do texto, que é o pior sintoma, mesmo sem
   conseguir empilhar o cabeçalho. */
@supports not selector(:has(*)) {
  @media (max-width: 767px) {
    .shadow-card .flex.gap-3 > .p-2.rounded-lg { flex-shrink: 0; }
    .shadow-card .flex.gap-3 > .p-2.rounded-lg + div { min-width: 0; flex: 1 1 0%; }
    .shadow-card .flex.gap-3 > .p-2.rounded-lg + div > .flex.items-center.gap-2 {
      flex-wrap: wrap;
    }
  }
}

/* ---------------------------------------------------------------------
 * 13. Arrastar o card do Kanban tocando nele
 *
 * Descoberta da versão 1.7: os listeners do dnd-kit não ficam no card, e
 * sim num BOTÃO DE ALÇA (o ⠿) de ~18px dentro dele:
 *
 *   <div ref=setNodeRef onClick=abrirDetalhe class="bg-white rounded-xl …">
 *     <div class="flex items-start gap-2">
 *       <button {...attributes} {...listeners} class="mt-0.5 p-0.5">⠿</button>
 *
 * Duas consequências:
 *
 *   1. O seletor [aria-roledescription] das versões 1.3–1.5 mirava a ALÇA,
 *      não o card. Por isso o `touch-action` nunca chegou onde o dedo toca.
 *   2. Acertar 18px com o dedo é inviável — daí o "impossível mover".
 *
 * O encaminhamento do toque (card → alça) está no script de index.html.
 * Aqui vai o que é de CSS.
 * ------------------------------------------------------------------- */
@media (pointer: coarse) {

  /* a) A alça vira um alvo de verdade (reserva, caso o encaminhamento
   *    não funcione em algum navegador). Cresce a área de toque sem
   *    empurrar o layout, usando padding negativo compensado. */
  [aria-roledescription="sortable"],
  [aria-roledescription="draggable"] {
    min-width: 34px;
    min-height: 34px;
    display: inline-flex;
    align-items: center;
    justify-content: center;
    margin: -8px 0 -8px -8px;   /* neutraliza o crescimento no layout */
  }

  /* b) O `touch-action` precisa estar onde o dedo encosta: o CARD.
   *    `manipulation` mantém a rolagem funcionando e só tira o atraso
   *    de 300ms do duplo-toque. */
  .bg-white.rounded-xl:has(> * > [aria-roledescription="sortable"]),
  .bg-white.rounded-xl:has(> * > [aria-roledescription="draggable"]) {
    touch-action: manipulation;
    -webkit-tap-highlight-color: transparent;
  }

  /* c) (removido na 1.8 — mesma razão: touch-action não vale mid-gesture) */

  /* d) Os botões de ação do card (editar/arquivar/excluir) são
   *    `opacity-0 group-hover:opacity-100` — no celular não existe hover,
   *    então ficam invisíveis mas continuam ocupando área de toque e
   *    engolindo o gesto. Tornar visíveis resolve os dois problemas:
   *    o usuário passa a vê-los, e para de esbarrar neles sem querer. */
  .bg-white.rounded-xl .opacity-0.group-hover\:opacity-100 {
    opacity: 1;
  }
}

/* ---------------------------------------------------------------------
 * 9. Os botões flutuantes cobrem o botão do modal (4.3)
 *
 * O grupo de botões redondos (chat e notificações) é
 * `.fixed.bottom-5.right-5.z-50` — 20px acima da borda inferior. No
 * desktop sobra tela de sobra; no celular, um modal ocupa quase tudo e a
 * linha de botões dele ("Cancelar" / "Registrar") cai exatamente ali
 * atrás. O usuário toca no chat achando que está confirmando.
 *
 * O selo do reCAPTCHA vive no mesmo canto e pelo mesmo motivo.
 *
 * Sobem os dois, e só no celular: é onde o problema existe.
 *
 * Por que CSS e não JavaScript: dava para subir os botões apenas
 * enquanto um modal estivesse aberto, mas isso exigiria reconhecer "modal
 * aberto" num bundle sem código-fonte — âncora frágil, para um ganho que
 * é ter os botões 4rem mais baixos quando não há modal nenhum.
 * ------------------------------------------------------------------- */
@media (max-width: 767px) {
  /* 7rem: a linha de botões do modal tem ~56px de altura e encosta na borda
     de baixo. 6rem (4.3) passava raspando; 7rem deixa folga visível. */
  .fixed.bottom-5.right-5.z-50 {
    bottom: 7rem;
  }

  /* O selo do Google fica ABAIXO do botão de chat (4.11), fechando a coluna:
     notificação, chat, selo. 2,5rem = a base do chat (7rem) menos a altura do
     selo (60px) e um respiro.

     Ele volta a ficar na faixa do rodapé de um modal aberto — e é aceitável
     onde não era para os botões: o selo não é alvo de toque, é atribuição.
     Cobrir um botão impede a ação; cobrir um selo atrapalha a vista. */
  .grecaptcha-badge {
    bottom: 2.5rem !important;
  }
}

/* ---------------------------------------------------------------------
 * 10. Os dois botões flutuantes viram uma coluna (4.7)
 *
 * São DOIS containers, não um — e foi isso que a 4.3/4.6 não viu:
 *
 *   .fixed.bottom-5.right-5        notificações (azul)
 *   .fixed.bottom-5.right-[76px]   chat (verde, 48px)
 *
 * O segundo fica 76px à esquerda do primeiro: lado a lado. Como só o
 * primeiro tinha sido subido, os dois ficaram na diagonal — um problema
 * novo, criado pela correção do anterior.
 *
 * Agora os dois dividem a mesma coluna (`right: 1.25rem`), com o CHAT
 * embaixo e a notificação em cima, empilhados:
 *
 *      [ notificação ]   bottom = 7rem + 60px
 *      [ chat        ]   bottom = 7rem
 *      ─────────────── botão do modal, livre
 *
 * 60px = os 48px do botão de chat mais 12px de respiro. O cálculo se
 * apoia na altura do botão DE BAIXO, que é a única que importa para os
 * dois não se tocarem.
 *
 * Só no celular: no desktop eles cabem lado a lado sem cobrir nada, e
 * mexer no que não incomoda é como se criou o problema desta seção.
 * ------------------------------------------------------------------- */
@media (max-width: 767px) {
  /* Chat: sai dos 76px e vira o de baixo da coluna. */
  .fixed.bottom-5.right-\[76px\].z-50 {
    right: 1.25rem;
    bottom: 7rem;
  }

  /* Notificações: sobe mais uma altura de botão, para ficar acima do chat. */
  .fixed.bottom-5.right-5.z-50 {
    bottom: calc(7rem + 60px);
  }
}

/* ---------------------------------------------------------------------
 * 11. Cabeçalho da tela: título ACIMA dos botões, no celular (4.9)
 *
 * O cabeçalho mobile é `título+subtítulo | ações`, lado a lado. Com dois
 * botões — Produtos ("Nova categoria" + "Novo produto") e Embalagens
 * ("Nova movimentação" + "Nova embalagem") — o título vira "Pro…" e o
 * segundo botão sai pela borda direita.
 *
 * O container das ações é `flex-shrink-0`: ele NÃO encolhe, então nem o
 * `flex-wrap` que já tem chega a valer — em vez de quebrar, transborda.
 *
 * A correção põe o título numa linha inteira (`flex: 1 1 100%`), o que
 * empurra as ações para a linha de baixo, onde elas têm a largura toda e
 * aí sim podem quebrar entre si.
 *
 * Vale para todas as telas, e não só para as duas reclamadas: numa tela
 * estreita, título espremido ao lado de botão é o mesmo problema em
 * qualquer lugar. Onde só há um botão pequeno, a linha extra é o preço —
 * e é barato perto de um título ilegível.
 * ------------------------------------------------------------------- */
@media (max-width: 767px) {
  .md\:hidden.flex.items-center.justify-between.gap-2.px-3.py-2 {
    flex-wrap: wrap;
    align-items: flex-start;
  }

  .md\:hidden.flex.items-center.justify-between.gap-2.px-3.py-2 > .min-w-0.flex-1 {
    flex: 1 1 100%;
  }

  .md\:hidden.flex.items-center.justify-between.gap-2.px-3.py-2 > .flex-shrink-0 {
    flex: 1 1 100%;
    flex-shrink: 1;
    justify-content: flex-start;
  }
}

/* ---------------------------------------------------------------------
 * 12. Tabela larga rola para o lado — sem mexer no card (4.9, refeita na 4.12)
 *
 * As tabelas de Produtos e Embalagens ficam num card com `overflow-hidden`,
 * que não esconde só o excesso: **corta**, sem deixar rolar.
 *
 * A primeira tentativa (4.9) trocou o card para `overflow-x: auto`. Funciona
 * para a tabela, mas tem um efeito colateral sério: com `overflow-x: auto` e
 * `overflow-y: hidden`, o card passa a CORTAR na vertical. Onde algum
 * ancestral limita a altura, o conteúdo some sem jeito de rolar — e a tela
 * parece travada.
 *
 * Agora o card fica como está, e quem rola é um `div` novo em volta da
 * TABELA, criado pelo script de mobile (`sf-tabela-rolante`, em index.html).
 * O elemento que rola nasce para isso e não tem outro papel no layout: não
 * há como ele cortar o que não é dele.
 * ------------------------------------------------------------------- */
@media (max-width: 767px) {
  .sf-tabela-rolante {
    overflow-x: auto;
    -webkit-overflow-scrolling: touch;
  }
}

/* ---------------------------------------------------------------------
 * 13. Os dois painéis injetados que não cabiam (4.9)
 *
 * a) WhatsApp, "Números e quem recebe": a linha é
 *    `nome | telefone (w-40) | Ped | Ret`. Os 160px do telefone comiam a
 *    largura das duas caixas de marcar, que saíam pela direita — e o
 *    nome, que é `flex-1`, sumia antes. Telefone menor resolve os dois,
 *    e `flex-wrap` é a rede de segurança para telas ainda mais estreitas.
 *
 * b) Armazéns, "Tipo de armazém": nome e seleção lado a lado cortavam os
 *    dois textos ("2 - C2K Part…" e "Fábrica (consome in…"). No celular
 *    viram duas linhas, com a seleção ocupando a largura inteira — que é
 *    onde o texto da opção finalmente cabe.
 * ------------------------------------------------------------------- */
@media (max-width: 767px) {
  [data-wa-linha] {
    flex-wrap: wrap;
  }

  [data-wa-linha] input[type="tel"] {
    width: 7.5rem;
  }

  [data-armazem-lista] > div {
    flex-direction: column;
    align-items: stretch;
    gap: 0.5rem;
  }

  [data-armazem-lista] select {
    width: 100%;
  }
}

/* ---------------------------------------------------------------------
 * 14. Filtro de período em duas linhas, no celular (4.10)
 *
 * Em Estoque o filtro é uma linha só:
 *
 *     Período: [mês inicial] até [mês final] [limpar]
 *
 * Em 375px isso não cabe: o "até" e o segundo mês ficam fora da tela.
 *
 * A solução NÃO é `flex-wrap`. Com ele a quebra cai onde sobrar espaço —
 * que costuma ser no meio de "Período: [mês", deixando o rótulo separado
 * do campo a que ele se refere. O que se quer é uma quebra em lugar fixo.
 *
 * Por isso o grupo vira uma GRADE de duas colunas: rótulo na primeira,
 * campo na segunda. Cada par cai numa linha por construção —
 *
 *     Período:  [mês inicial]
 *     até       [mês final]
 *     [limpar]
 *
 * — e o alinhamento entre os dois campos sai de graça, que era o outro
 * defeito da linha única.
 *
 * A âncora é `:has(> label + input[type="month"])`: um grupo cujo rótulo
 * é seguido direto por um campo de mês. Descreve o papel do bloco, não a
 * aparência dele. Sem `:has()`, nada muda — degradação sem estrago.
 * ------------------------------------------------------------------- */
@media (max-width: 767px) {
  .flex.items-center.gap-2:has(> label + input[type="month"]) {
    display: grid;
    grid-template-columns: auto minmax(0, 1fr);
    align-items: center;
    gap: 0.5rem;
  }

  /* Os campos ocupam a coluna toda: é o que alinha um sob o outro. */
  .flex.items-center.gap-2:has(> label + input[type="month"]) > input[type="month"] {
    width: 100%;
  }

  /* O "até" vira rótulo da segunda linha, alinhado com "Período:". */
  .flex.items-center.gap-2:has(> label + input[type="month"]) > span {
    justify-self: start;
  }

  /* O botão de limpar não estica junto com a grade. */
  .flex.items-center.gap-2:has(> label + input[type="month"]) > button {
    justify-self: start;
  }
}

/* ---------------------------------------------------------------------
 * 15. Seleção + botão na mesma linha, no celular (4.10)
 *
 * Em Planejamento de Produtos, o cabeçalho do bloco "Plano de produção"
 * termina com:
 *
 *     [ Adicionar produto…  (max-w-260px) ] [ Adicionar ]
 *
 * Em 375px sobram ~343px depois das margens, e os 260px da seleção mais
 * o botão passam disso: o "Adicionar" fica cortado na borda.
 *
 * A seleção passa a ENCOLHER (`flex: 1 1 8rem`, `max-width: none`) e o
 * botão a não encolher. Assim quem cede espaço é o campo, que tem texto
 * longo e tolera corte, e não o botão, que é o alvo do toque — um botão
 * pela metade não é um botão menor, é um botão que não dá para acertar.
 *
 * A âncora `:has(> select + button)` descreve o padrão "campo seguido do
 * botão que age sobre ele", que vale em qualquer tela onde apareça.
 * ------------------------------------------------------------------- */
@media (max-width: 767px) {
  .flex.items-center.gap-2:has(> select + button) {
    flex-wrap: wrap;
    width: 100%;
  }

  .flex.items-center.gap-2:has(> select + button) > select {
    flex: 1 1 8rem;
    min-width: 0;
    max-width: none;
  }

  .flex.items-center.gap-2:has(> select + button) > button {
    flex-shrink: 0;
  }
}

/* ---------------------------------------------------------------------
 * 16. Filtros de Estoque em duas linhas (4.12)
 *
 * A linha é `[Todos os tipos (w-44)] [Todos os armazéns (w-52)] [Período…]`
 * dentro de um `flex flex-wrap gap-3`. Em 375px as duas seleções somam
 * 384px e já não cabem juntas: cada uma vai para uma linha, e o período
 * para uma terceira — três linhas para três controles.
 *
 * O pedido é o arranjo que faz sentido: as duas seleções dividem a
 * primeira linha e o período fica na segunda, inteira para ele (onde a
 * grade da seção 14 o quebra em "Período:" e "até").
 *
 * Para as duas caberem lado a lado elas precisam PODER encolher —
 * `w-44`/`w-52` são larguras fixas. `flex: 1 1 0` com `min-width: 0` faz
 * as duas dividirem a linha em partes iguais, qualquer que seja a tela.
 * ------------------------------------------------------------------- */
@media (max-width: 767px) {
  .flex.flex-wrap.gap-3.items-center > .w-44,
  .flex.flex-wrap.gap-3.items-center > .w-52 {
    flex: 1 1 0;
    min-width: 0;
    width: auto;
  }

  /* O grupo do período ocupa a linha inteira, abaixo das duas seleções. */
  .flex.flex-wrap.gap-3.items-center > .flex.items-center.gap-2:has(> label + input[type="month"]) {
    flex: 1 1 100%;
  }
}