/* =========================================================================================
   FAMILIA `header > .container` -- a folha COMPARTILHADA das 20 paginas do site que servem o
   menu desktop por `header .container` (sem `nav.navbar`, que e o molde da home e das 24
   paginas da 6.emenda33).

   POR QUE ESTE ARQUIVO EXISTE (6.emenda104, 17/09/2026)
   ----------------------------------------------------
   A 6.emenda81 consertou o header de `crm.html` e `fiscal.html` COPIANDO o mesmo bloco
   `@media` nos DOIS arquivos -- 2.488 bytes byte-identicos, sha256 77e9f89d26558f59 nos dois.
   Copia nao e conserto de familia: a terceira pagina da familia nasce sem a faixa compacta, e
   foi exatamente o que o censo absoluto de scrollWidth mediu depois (Chromium do harness de
   tests/unit/test_site_dotcompany_paginas_internas_e_a11y.py, 59 paginas x 11 larguras x 2
   temas x topo/rolado, 17/09/2026), com a pagina inteira rolando na horizontal no DESKTOP:
       servicos.html     980 -> +98px    1024 -> +54px
       nfse.html         980 -> +49px    1024 ->  +5px
       nfsegratis.html   980 -> +13px
   O culpado e o MESMO das duas primeiras: `header .container` desenhado para 1200px+ servido a
   partir de 769px (`.nav-links` com `gap: 2rem` + `.header-cta` com `gap: 1rem` e dois `.btn`
   de `padding: .75rem 1.5rem`). Agora a regra mora AQUI, uma vez so, e vale para toda pagina da
   familia que carregar esta folha.

   NADA DE `overflow-x: hidden`: o conteudo tem de CABER, e nao de ser escondido. Esconder a
   rolagem deixaria o scrollWidth limpo com o menu ainda transbordando da propria caixa. Quem
   recusa esse remendo e `test_a_familia_nao_esconde_a_rolagem_com_overflow_hidden` (estatico,
   ratchet: as 17 ocorrencias herdadas de `body` so podem encolher, e esta folha nao tem
   nenhuma). O portao de scrollWidth tambem olha `header .container` direto, mas com a folga
   `LARGURA_DO_EMOJI` -- e NAO `estoura <= 0`, como esta linha afirmava ate 18/09/2026: o rotulo
   "Me viro sozinho" do CTA tem um EMOJI, e a fonte de fallback que o Chromium do harness
   escolhe muda a largura do mesmo `A.btn` em ate 82px entre cargas IDENTICAS. Cobrar zero ali
   seria um portao que sorteia; a afirmacao honesta e a do DOCUMENTO.

   ONDE ENTRA NA CASCATA: o `<link>` e o ULTIMO elemento do `<head>` de cada pagina da familia,
   depois de todo `<style>` inline. Assim empate de especificidade resolve a favor desta folha,
   e o CSS computado e IDENTICO ao que o bloco copiado produzia quando vivia no fim do `<head>`
   (gate `test_a_folha_da_familia_da_o_mesmo_css_computado_que_a_copia_dava`).

   DE 1200px EM DIANTE NADA MUDA -- o `.container` ja e fixo em 1152px e sobravam 24px.
   ========================================================================================= */

/* ---- PRIMEIRO DEGRAU: 769..1199px -------------------------------------------------------
   Medido com a DM Sans real, `DIV.header-cta` contra a caixa do proprio header:
       fiscal.html   980 -> +130,9px   1024 -> +86,9px   1100 -> +10,9px   1280 -> cabe
       crm.html      980 ->  +35,7px   1024 -> cabe      1100 -> cabe      1280 -> cabe
   `nowrap` no que nao pode quebrar em duas linhas, `gap` menor, fonte .85rem, CTA 10px 14px e
   logo 1.15rem.

   Os marcadores `@secao`/`@fim` abaixo NAO sao enfeite: o gate
   `test_a_folha_da_familia_da_o_mesmo_css_computado_que_a_copia_dava` recorta EXATAMENTE este
   pedaco e o serve INLINE, no lugar onde a copia vivia, para provar que mover a regra para ca
   nao mudou um byte do CSS computado de `DIV.header-cta`. Sem os marcadores o gate teria de
   adivinhar onde a secao comeca -- e gate que adivinha nao mede. */
/* @secao: header-compacto */
@media (min-width: 769px) and (max-width: 1199px) {
    header .container .nav-links a,
    header .container .header-cta .btn,
    header .container .header-cta > a,
    header .container .logo-text { white-space: nowrap; }
    header .container .nav-links { gap: 12px; }
    header .container .nav-links > a,
    header .container .nav-dropdown > a { font-size: .85rem; }
    header .container .header-cta { gap: 8px; }
    /* apertar a LARGURA nao pode encolher o ALVO. 769..1199 inclui o retrato de tablet
       (768/820 do aceite visual): a altura fica presa em 44px (WCAG 2.5.8) enquanto so o
       padding horizontal cede, que e o unico que conta para o transbordo. */
    header .container .header-cta .btn { padding: 10px 14px; font-size: .85rem;
                                         min-height: 44px; box-sizing: border-box; }
    header .container .logo-text { font-size: 1.15rem; }

    /* ---- O DEGRAU NAO BASTA SOZINHO, E ISSO FOI MEDIDO (6.emenda104 r2, 18/09/2026) --------
       O primeiro achado desta rodada nao e o transbordo -- e POR QUE ele ia e vinha. A r1
       registrou que o mesmo `A.btn` do CTA variava ate 82px entre cargas IDENTICAS e atribuiu
       isso a fonte de fallback do emoji. NAO E FONTE: o botao de autocadastro SORTEIA o proprio
       texto a cada carga (`selfRegisterTexts[Math.floor(Math.random() * ...)]`, sete rotulos,
       de "Me viro sozinho" a "Profissional aqui, deixa comigo!"). O "ruido" era o PRODUTO, e
       naquela faixa ele decidia no cara-ou-coroa se o visitante recebia rolagem horizontal.
       Medido com o rotulo PINADO no pior dos sete (2 temas x topo e rolado, carga limpa por
       largura, 18/09/2026), COM todo o resto desta folha no ar:
           nfse.html        769 -> +12   800 -> +4   900 -> +53   950 -> +53   979 -> +24
                            980 -> +23   1024..1199 -> cabe
           nfsegratis.html  769 -> +19 (ver a nota do menu suspenso, abaixo)
       Repare no 980: o portao absoluto MEDE essa largura e estava verde -- porque sorteava um
       rotulo curto. Nao havia "so a faixa cega"; havia um portao medindo uma pagina diferente a
       cada execucao. Por isso os dois consertos sao irmaos: o portao pina o pior caso, e o
       leiaute passa a caber NO pior caso.

       Anatomia de `nfse.html` a 769px (`.container` com 721px uteis):
           A.logo 108,7 + NAV.nav-links 403,2 (SEIS itens, com "Para Contadores" de 102,4px)
           + DIV.header-cta 272,6 = 784,5px -- e com o pior rotulo passa de 800.
       Faltam ~64px, e nao ha de onde tira-los: o texto ja esta em `.8rem` (12,8px, e 12px e o
       piso de legibilidade que a 6.emenda33 fixou), o `gap` ja caiu para 8px/6px e o padding do
       botao ja esta em 8px 10px. Espremer mais seria trocar um defeito visivel por um ilegivel.

       ENTAO ELE USA DUAS LINHAS -- que e a regra da casa para tela apertada: quebrar, nunca
       espremer. `flex-wrap: wrap` e uma NAO-OPERACAO enquanto o conteudo cabe (e a definicao do
       flexbox), entao as paginas que ja cabiam continuam com o MESMO leiaute, pixel a pixel
       (cobrado por `test_a_quebra_nao_move_um_pixel_onde_o_conteudo_ja_cabia`).

       E FOI ESSE GATE QUE ACHOU O TERCEIRO DEFEITO, o que nenhum portao de rolagem podia ver.
       Ele reprovou em `fiscal.html` e `nfsegratis.html` a 769px, paginas que o censo dava por
       BOAS. Medindo o que ele acusou, com a folha ANTERIOR no ar:
           fiscal.html@769       `A.logo` com caixa de 114,5px e conteudo de 139px
                                 (`scrollWidth - clientWidth = 24`), `NAV.nav-links` comecando em
                                 138,5 e o texto do logo indo ate 162,7 -- ou seja, "DotCompany"
                                 impresso POR BAIXO de "Home".
           nfsegratis.html@769   o mesmo, 30px de conteudo fora da caixa, MAIS 25px de rolagem.
       Elas nao cabiam: cabiam ESMAGANDO o logo. `flex-shrink` encolhe a CAIXA, nao o TEXTO --
       ele sai por baixo do vizinho e o `scrollWidth` do documento continua limpo. Com a quebra,
       o flexbox parte a linha ANTES de encolher (essa e a ordem do algoritmo) e o logo volta
       inteiro. Nas duas, `scrollWidth - clientWidth` do logo passou a ser ZERO.

       E a folga que
       isso cria e o que torna a medida ESTAVEL: com nfse.html a 769px, linha 1 (logo + menu)
       usa 511,9px de 721 e linha 2 (o CTA) 272,6px de 721 -- mais de 200px de sobra em CADA
       uma, o que engole qualquer um dos sete rotulos.

       ELE VALE NA FAIXA INTEIRA, 769..1199, e nao so em 769..899: com o rotulo pinado no pior
       caso `nfse.html` estourava ate 979 (+24) e ate 980 (+23). Um degrau que para no 899
       deixaria justamente esse pedaco de pe.

       O `row-gap` existe porque sem ele as duas linhas se encostam: o `.header` e `position:
       sticky` nas 20 paginas da familia (medido), nao `fixed` com altura chumbada, entao a
       segunda linha EMPURRA a pagina em vez de cobrir conteudo -- e por isso quebrar aqui e
       seguro.

       O `margin-inline: auto` do menu NAO e enfeite, e conserta um defeito que a propria quebra
       CRIARIA. Com `justify-content: space-between` e a linha 1 tendo so DOIS itens, o menu ia
       para o canto direito; ai o `DIV.nav-dropdown-menu` -- que e `position: absolute`,
       `left: 50%`, `translateX(-50%)`, 401px de largura, e que continua OCUPANDO LAYOUT mesmo
       fechado (`visibility: hidden`, nao `display: none`) -- passava a furar a tela: medido em
       nfsegratis.html@769, +19px de rolagem com o header inteiro cabendo. Com as duas margens
       automaticas o menu fica CENTRADO na sobra, e o suspenso volta para dentro.
       E POR QUE ISSO NAO MUDA NADA ONDE CABE: com tres itens numa linha so, duas margens `auto`
       no item do meio repartem a sobra em duas metades iguais -- exatamente o que
       `space-between` ja fazia. Nao e parecido: e o mesmo numero, e o gate acima compara os
       retangulos de TODOS os filhos do header, largura a largura, para provar isso.

       Os marcadores `@regra`/`@fimregra` abaixo NAO sao enfeite, pela mesma razao que os
       `@secao`: o mutante `test_mutante_r2_sem_a_quebra_a_familia_volta_a_rolar_na_faixa`
       arranca EXATAMENTE este pedaco e re-serve a folha sem ele, para provar que quem segura
       nfse.html hoje e esta regra -- e nao alguma outra coisa que mudou junto. Mutante que
       adivinha onde cortar nao mede. */
    /* @regra: quebra-em-duas-linhas */
    header .container { flex-wrap: wrap; row-gap: 10px; }
    header .container .nav-links { margin-inline: auto; }
    /* @fimregra: quebra-em-duas-linhas */
}
/* @fim: header-compacto */

/* ---- SEGUNDO DEGRAU: 769..899px ---------------------------------------------------------
   O primeiro degrau nao chega em 769..899: as paginas da familia que carregam 3 menus
   suspensos alem dos links soltos continuavam estourando. MEDIDO em 17/09/2026, JA com o
   primeiro degrau no ar (`document.documentElement.scrollWidth` alem da tela):
       nfse.html        769 -> +98px   800 -> +67px
       fiscal.html      769 -> +57px   800 -> +26px
       nfsegratis.html  769 -> +55px   800 -> +24px
       servicos.html    769 -> +13px   800 -> cabe
   Este bloco nasceu INLINE em fiscal.html na 6.emenda81 -- e ao mover o primeiro degrau para
   esta folha ele PAROU DE VALER: os dois blocos tem a mesma especificidade e a folha passou a
   vir depois, entao 769..899 voltava a receber os valores do primeiro degrau. Foi medido, nao
   suposto (fiscal 769 voltou a +57px). Por isso ele vive AQUI, depois do primeiro degrau: a
   ordem entre os dois degraus e load-bearing.
   De 900px em diante o primeiro degrau ja resolve -- este bloco NAO toca a faixa que funciona. */
/* @secao: header-estreito */
@media (min-width: 769px) and (max-width: 899px) {
    header .container .nav-links { gap: 8px; }
    header .container .nav-links > a,
    header .container .nav-dropdown > a { font-size: .8rem; }
    header .container .header-cta { gap: 6px; }
    header .container .header-cta .btn { padding: 8px 10px; font-size: .8rem;
                                         min-height: 44px; box-sizing: border-box; }
    header .container .logo-text { font-size: 1rem; }
    header .container .logo-img { height: 30px; }
}
/* @fim: header-estreito */

/* ---- GRADES QUE TEM DE CABER ------------------------------------------------------------
   Mesma doenca do header, outro lugar: grade desenhada para um numero de colunas que o
   CONTEUDO nao sustenta. Um item de grid tem `min-width: auto`, e isso poe um PISO de
   min-content em cada trilha `1fr` -- a grade entao cresce alem da propria caixa e empurra o
   documento. MEDIDO em 17/09/2026 (`DIV.stats-grid`, scrollWidth vs clientWidth da PROPRIA
   grade, 8 cartoes em `repeat(6, 1fr)`):
       catalogo.html   1025 -> +221px   1100 -> +146px   1200..1920 -> +46px
       api.html        1025 -> +238px   1100 -> +163px   1200..1920 -> +63px
   Repare no 1200..1920: a grade estourava a caixa em TODA largura de desktop -- so nao virava
   barra de rolagem porque o `.container` e centrado e sobrava margem na tela. O visitante via
   os cartoes desalinhados do resto da pagina; a 1100 e a 1200 virava rolagem de verdade
   (+122px e +22px em catalogo, +139px e +39px em api).
   DUAS regras, e a ordem das duas importa:
     (1) `min-width: 0` tira o piso de min-content -- e o invariante da familia, e nao muda UM
         PIXEL onde o conteudo ja cabia (medido nas 9 larguras);
     (2) a escada de colunas continua sendo decisao da PAGINA. `.stats-grid` so existe no DOM
         de catalogo.html e api.html (as outras 4 paginas da familia que tem a REGRA nao tem a
         MARCACAO -- medido no DOM, nao por grep), as duas com os MESMOS 8 cartoes, e 8 em 4
         colunas e a continuacao natural da escada que a propria pagina ja usa (2 no celular,
         3 ate 1024). A 1025 isso da 220px por coluna (172 uteis) contra os 155px do maior
         valor -- cabe com folga, sem quebrar palavra no meio.
   `overflow-wrap` e a REDE DE SEGURANCA: se um dia o texto crescer, ele quebra dentro do
   cartao em vez de furar a caixa. */
.stats-grid > *,
.solution-stats > * { min-width: 0; }

.stats-grid .stat-value,
.stats-grid .stat-label,
.solution-stats .solution-stat-value,
.solution-stats .solution-stat-label { overflow-wrap: break-word; }

@media (min-width: 1025px) {
    .stats-grid { grid-template-columns: repeat(4, minmax(0, 1fr)); }
}
