/* ============================================================================================
   ExiZap — CAMADA DE ACESSIBILIDADE (WCAG 2.2 AA), ISOLADA ATRÁS DE `.theme-a11y`.

   COMO LIGAR: cookie `ez-a11y=1`. O `_Layout` e o `_LayoutGuest` leem esse cookie e põem a
   classe no `<body>`. Sem o cookie, ESTA FOLHA INTEIRA É INERTE — não há um seletor aqui que
   case sem `.theme-a11y`, e isso é asserção, não promessa:
   `node NewExiZap.Verificacao/front/contraste-wcag.test.js` (bloco 3) reprova o arquivo se
   qualquer seletor escapar do escopo.

   ⚠️ POR QUE UM ARQUIVO SÓ, e não `.theme-a11y` espalhado nas seis folhas: reversibilidade.
   Reverter a camada é apagar um `<link>`; e "com a flag desligada nada muda" passa a ser
   verificável lendo UM arquivo, em vez de auditar 1.400 seletores em seis.

   ────────────────────────────────────────────────────────────────────────────────────────────
   ⚠️ AS DUAS FAIXAS, DE NOVO — e aqui a razão é medida, não estilística.

   O briefing pediu UM token `--brand-strong` para "links, textos de ação e botões primários com
   texto branco". No tema claro isso fecha: `#0e7c88` dá 4,93:1 sobre branco E carrega branco a
   4,93:1. No escuro NÃO fecha, e não é questão de escolher melhor o valor:

     · como TEXTO sobre `--surface` (#122329), `#0e7c88` cai para 3,28:1 — precisa CLAREAR;
     · como FUNDO carregando branco, clarear é exatamente o que não se pode fazer.

   São dois papéis opostos no mesmo token. Daí a separação: `--brand-strong` é TEXTO e tem par
   claro/escuro; `--brand-solido` é FUNDO e tem valor único. É a mesma lição que o
   `exizap-theme.css` registra sobre `--ok`: medir contra um fundo só é meio teste.

   ⚠️ E A PRIMEIRA VERSÃO DESTA FOLHA ATRIBUIU OS PAPÉIS AO CONTRÁRIO, com `--brand-strong` como
   fundo. Parecia defensável e era errado por duas razões que só a medida mostrou: o próprio
   tema diz "a variante `-strong` existe para texto, e só", e as 52 páginas com `<style>` próprio
   têm 121 usos de `color:var(--brand-strong)` contra ZERO de `background:`. O token já era de
   texto no produto; eu o reatribuí e quebrei 23 regras de página no tema escuro. O erro só
   apareceu abrindo as 44 telas no escuro — nenhum arnês estático podia vê-lo, porque cada regra
   estava correta isoladamente.

   A MESMA ARMADILHA ACONTECEU TRÊS VEZES nesta branch, com três tokens diferentes
   (`--ok-strong` no botão Resolver, `--ci-pres-on` no contador do chat, `--primary-fg` no
   `.btn-primary`): usar como FUNDO um token que clareia no tema escuro. Cada vez o texto branco
   em cima caiu para ~2:1. A regra que ficou: token com par claro/escuro é de TEXTO; fundo que
   carrega branco pede valor fixo, e o nome dele termina em `-solido`.

   ⚠️ E O VENDOR É O INVERSO DO NOSSO. `nanite-theme.min.css` define os semânticos UMA vez e
   nunca os redefine no bloco escuro — eles foram escolhidos para fundo escuro. Medido em 29/09:

     utilitário      claro        escuro       usos
     text-warning    1,59:1 ✗     10,17:1 ✓     17
     text-success    2,02:1 ✗      8,00:1 ✓     38
     text-info       2,55:1 ✗      6,34:1 ✓     25
     text-danger     3,05:1 ✗      5,31:1 ✓     76
     text-primary    3,32:1 ✗      4,88:1 ✓     23
     text-muted      6,08:1 ✓      3,63:1 ✗    943   ← o inverso, e o de maior alcance

   `text-muted` merece a nota: são 943 usos (643 .cshtml + 300 .js), o vendor o resolve por
   `--nano-secondary-color`, e ele é `rgba(39,47,55,.75)` no claro (6,08:1, passa) e `#6b7987`
   no escuro (3,63:1, reprova). Nosso `--muted` falha no tema OPOSTO: 3,42:1 no claro e 6,09:1
   no escuro. São dois cinzas diferentes, cada um quebrado num tema — e é por isso que cada um
   é consertado no tema em que quebra, e só nele.

   ⚠️ `!important` AQUI É OBRIGATÓRIO, NÃO PREGUIÇA. As regras `.text-*` do vendor declaram
   `!important` elas mesmas (`color: rgba(var(--nano-warning-rgb),…) !important`). Override sem
   `!important` é inerte, por mais específico que seja — é o mesmo defeito do "apagão de foco do
   vendor" que já custou uma rodada de revisão nesta série. Só as regras que disputam com o
   vendor o usam; nenhuma outra.
   ============================================================================================ */

/* ── ETAPA 1 — TOKENS ─────────────────────────────────────────────────────────────────────────
   Toda razão abaixo foi medida por `NewExiZap.Verificacao/front/wcag-cor.js` contra a superfície
   REAL do papel: `--surface` do tema, a tinta composta do selo, ou o fundo próprio do trilho. */
.theme-a11y {
    /* Marca. `--brand` (#15B5C6) NÃO muda: segue no logo, no trilho escuro, no selo e no ícone
       decorativo, que é onde ela passa (6,19:1 sobre #0F2830). */
    /* ⚠️ CORREÇÃO DE PAPEL, feita depois de abrir as 44 telas no tema ESCURO. A Etapa 1
       tratou `--brand-strong` como FUNDO sólido, e isso contrariava o próprio tema, que
       registra: "A variante `-strong` existe para texto, e só". A medida encerrou a dúvida —
       nas 52 páginas com `<style>` próprio há 121 usos de `color:var(--brand-strong)` e ZERO
       de `background:var(--brand-strong)`. Como fundo fixo, ele reprovava como TEXTO no escuro
       (3,28:1 sobre #122329) e derrubava 23 regras de página de uma vez: cabeçalho de coluna
       do calendário, título de seção de pedido, link. Nenhum arnês estático veria, porque o
       token estava "certo" e o papel errado.
       Agora `--brand-strong` é TEXTO e tem par claro/escuro, e o fundo sólido tem nome próprio. */
    --brand-strong: #0e7c88;      /* TEXTO de ação — 4,93:1 sobre branco. Era #0C8695: 4,32:1 */
    --brand-solido: #0e7c88;      /* FUNDO sólido que carrega branco — 4,93:1, igual nos dois temas */
    --brand-fg: var(--brand-strong);   /* apelido: as regras desta camada usam este nome */
    --brand-on-tint: #0b6f7a;     /* texto sobre tinta clara de marca — 5,27:1 sobre 12% de #15B5C6
                                     e 5,31:1 sobre --info-soft (#E3F7FA). #0e7c88 daria 4,42:1:
                                     a tinta baixa o contraste, e por isso o token é separado. */

    /* Papel de texto e de contorno. */
    --muted: #5b6f74;             /* 5,29:1 sobre branco, 5,03:1 sobre --bg e 4,77:1 sobre a tinta --info-soft.
                                     Era #7B8E95 (3,42:1). E era #5f7479 nesta camada, que dava
                                     4,93:1 sobre branco e REPROVAVA sobre a tinta por 0,05
                                     (4,45:1) — medido em quatro rótulos de KPI do /Relatorios.
                                     Escurecer o token resolve a classe inteira; um
                                     `--muted-on-tint` exigiria achar caso por caso onde há tinta */
    --control-border: #7B8E95;    /* 3,42:1 sobre #fff e 4,73:1 sobre #122329 (1.4.11 pede 3:1).
                                     É o valor MAIS CLARO que passa nos dois — `--border`
                                     (#E1E9EC) dá 1,23:1. Reusa --n-500, sem matiz nova. */
    --danger-fg: #c0203f;         /* 5,97:1 — família ROSA (aviso da janela de 24 h, text-danger).
                                     ⚠️ NÃO é apelido de `--danger-strong`: aquele é a família
                                     VERMELHA (#B42318, matiz ~4°) e tem 47 usos. Esta é ~350°,
                                     a matiz do #fa5c7c do vendor. Unificar as duas mudaria a
                                     matiz do aviso, que o briefing proíbe. Duas matizes de
                                     origem, dois tokens. */
    --info-fg: #20718a;           /* 5,54:1 — matiz do #39afd1 do vendor, escurecida */
    --primary-fg: #0b5ed7;        /* TEXTO — 5,84:1. Matiz do #2c8ef8 do vendor, escurecida */
    --primary-solido: #0b5ed7;    /* FUNDO sólido que carrega branco — 5,84:1 nos dois temas.
                                     ⚠️ A primeira versão do `.btn-primary` usou `--primary-fg`
                                     como FUNDO, e ele clareia no escuro (#7ab5fb): branco sobre
                                     ele dá 1,90:1. Quinze botões "Go Back" reprovaram no escuro
                                     por isso — o mesmo erro do `--ok-strong` no botão Resolver,
                                     cometido de novo trinta linhas depois de eu escrever a nota
                                     que o explica. Papel de fundo pede valor fixo. */
    --rail-cap: #7d9ba2;          /* 5,18:1 sobre #0F2830 e 6,29:1 sobre #0a1417.
                                     O briefing sugeriu #9fbac1 como PONTO DE PARTIDA; #9fbac1 é
                                     a cor do próprio item de menu, e igualar os dois apaga a
                                     hierarquia do trilho. #7d9ba2 é o mais claro que passa e
                                     segue visivelmente abaixo do item. */

    /* ⚠️ `--success-strong` É FUNDO SÓLIDO, NÃO APELIDO — e a primeira versão desta folha errou
       isso. Ela escreveu `--success-strong: var(--ok-strong)`, e `--ok-strong` tem par
       claro/escuro feito para TEXTO: no escuro ele vale #3CCB8E, um verde CLARO. O botão
       "Resolver" e o contador de não lidas carregam texto BRANCO, e branco sobre #3CCB8E dá
       2,07:1 — a flag teria consertado o tema claro e quebrado o escuro, que é exatamente o
       acidente do `--ok` que o `exizap-theme.css` registra. O arnês pegou.

       Valor fixo nos dois temas, como `--brand-strong`, pelo mesmo motivo: o botão é uma peça
       autocontida, e branco sobre #0B7A47 dá 5,40:1 em qualquer fundo de página.

       ⚠️ O briefing pedia #087f5b aqui (5,00:1 sobre branco). Medido e RECUSADO: sobre a tinta
       do chip verde (16% de #0acf97) ele dá 4,40:1 e reprova, enquanto o #0B7A47 que já está no
       produto dá 4,75:1. Um valor que serve ao botão e não serve ao chip não é um token só. */
    --success-strong: #0B7A47;    /* FUNDO sólido com texto branco — 5,40:1, igual nos dois temas */

    /* Este sim é apelido: `--warn-strong` já tem par claro/escuro e os dois passam
       (#9a6a00/4,73:1 e #FFC24D/10,07:1), e o único papel dele é TEXTO. */
    --warning-fg: var(--warn-strong);

    /* ⚠️ `--sidebar-bg` E `--sidebar-text` FORAM DEFINIDOS AQUI E REMOVIDOS DEPOIS, e a nota
       fica no lugar deles. O briefing pedia os dois por nome; eu os criei, e o bloco 11 do
       arnês mostrou que NINGUÉM OS LÊ — o produto escreve `background:var(--c-ink)` e
       `color:#9fbac1` direto nas regras de `.ez-rail`, e os dois já passam (15,37:1 e 7,51:1
       sobre o trilho). Token definido e nunca lido é a armadilha dos "três verdes" pelo avesso:
       a intenção fica documentada, o valor de verdade continua espalhado, e a próxima pessoa
       acredita que mudar o token muda a tela. Se algum dia o trilho for tokenizado, é ali que
       os nomes entram, com um leitor. */
}

/* ⚠️ A ORDEM DA CASCATA É ARMADILHA AQUI. `[data-theme=dark]` e `.theme-a11y` têm a MESMA
   especificidade (0,1,0), e esta folha carrega depois do tema — então `.theme-a11y{--muted:…}`
   sobrescreveria o `--muted` do tema escuro também. Todo token com par claro/escuro TEM de
   reaparecer abaixo, inclusive quando o valor é igual ao que o tema já põe. */
[data-theme=dark] .theme-a11y {
    --brand-strong: #15B5C6;      /* 6,51:1 sobre #122329 — o claro (#0e7c88) daria 3,28:1 */
    --brand-on-tint: #6FE0EA;     /* 7,77:1 sobre a tinta escura (14% de #35D0DE sobre #122329) */
    --muted: #8aa3aa;             /* 6,09:1 — é o valor que o tema escuro já dá; repetido de
                                     propósito, para que a linha acima não o engula */
    --danger-fg: #fa5c80;         /* 5,32:1 — no escuro a matiz rosa clara é a que passa */
    --info-fg: #6fd2ea;           /* 9,31:1 */
    --primary-fg: #7ab5fb;        /* 7,57:1 */
    /* ⚠️ A TINTA DE AVISO INVERTE NO ESCURO. `rgba(247,144,9,.16)` sobre `#122329` compõe
       `#373424` — um âmbar ESCURO. O `#7d5600` que serve ao tema claro dá 1,91:1 ali; o
       `--warn-strong` escuro (#FFC24D) dá 7,79:1. Mesma lógica de todo o resto: o par existe
       porque o fundo troca de polaridade, não porque a cor "é bonita" em cada tema. */
    --warn-on-tint: #FFC24D;      /* 7,79:1 sobre a tinta escura */
    /* --brand-strong NÃO reaparece de propósito: é FUNDO sólido, e branco sobre #0e7c88 dá
       4,93:1 em qualquer tema. Clareá-lo no escuro quebraria o texto branco que ele carrega. */
    /* --control-border NÃO reaparece: #7B8E95 dá 4,73:1 sobre #122329, acima do 3:1 exigido. */
}

/* ── ETAPA 2 — CORREÇÕES DE COR ───────────────────────────────────────────────────────────────
   Nada aqui inventa matiz: cada regra troca um valor por outro da MESMA família, escolhido por
   medição. Onde o valor de origem já passa, não há regra — `.btn-send.send-note` (#73510f sobre
   #ffc35a) dá 4,53:1 e ficou de fora de propósito. Consertar o que está certo é regressão. */

/* 2.1 — OS UTILITÁRIOS DO VENDOR. A maior alavanca da etapa: 1.122 usos somados, e todos
   falham no tema CLARO porque o `nanite-theme` escolheu essas cores para fundo escuro e nunca
   as redefiniu no bloco `[data-bs-theme=dark]`. `!important` é obrigatório aqui — a regra do
   vendor o declara, e sem ele o override é inerte por mais específico que seja. */
.theme-a11y .text-danger { color: var(--danger-fg) !important; }      /* 3,05:1 → 5,97:1 · 76 usos */
.theme-a11y .text-warning { color: var(--warning-fg) !important; }    /* 1,59:1 → 4,73:1 · 17 usos */
/* ⚠️ `.text-success` é TEXTO: usa `--ok-strong` (par claro/escuro), não `--success-strong`
   (fundo fixo). Trocar os dois deixaria o texto verde-escuro sobre painel escuro. */
.theme-a11y .text-success { color: var(--ok-strong) !important; }     /* 2,02:1 → 5,40:1 · 38 usos */
.theme-a11y .text-info { color: var(--info-fg) !important; }          /* 2,55:1 → 5,54:1 · 25 usos */
.theme-a11y .text-primary { color: var(--primary-fg) !important; }    /* 3,32:1 → 5,84:1 · 23 usos */

/* ⚠️ `text-muted` É O INVERSO, e é o de maior alcance: 943 usos. No claro o vendor o resolve
   para `rgba(39,47,55,.75)`, que composto sobre branco dá 6,08:1 e PASSA — mexer nele seria
   mudar o que está certo. No escuro ele vira `#6b7987` e cai para 3,63:1. Por isso a regra
   existe só dentro do tema escuro. */
[data-theme=dark] .theme-a11y .text-muted { color: #8aa3aa !important; }   /* 3,63:1 → 6,09:1 */

/* 2.2 — MARCA COMO FUNDO SÓLIDO CARREGANDO BRANCO. Era 2,48:1 em todos. */
.theme-a11y .btn-send,
.theme-a11y .fp-apply { background: var(--brand-solido); }
.theme-a11y .btn-ctx.primary { background: var(--brand-solido); border-color: var(--brand-solido); }
/* ⚠️ A BOLHA DE SAÍDA É O ITEM DE MAIOR ALCANCE DESTA ETAPA: é TODA mensagem enviada, em toda
   conversa. Branco sobre #15B5C6 dava 2,48:1 — o texto que o atendente mais lê era o pior par
   de contraste do produto. */
.theme-a11y .row-msg.out .bubble { background: var(--brand-solido); }   /* 2,48:1 → 4,93:1 */

/* 2.3 — VERDE COMO FUNDO SÓLIDO CARREGANDO BRANCO. Era 2,02:1 → 5,40:1.
   ⚠️ `--success-strong` e NÃO `--ok-strong`: o segundo clareia no tema escuro (#3CCB8E) porque
   o papel dele é texto, e branco sobre ele cai para 2,07:1. Ver a nota no bloco de tokens. */
.theme-a11y .btn-resolve { background: var(--success-strong); }         /* "Resolver" */
.theme-a11y .unread { background: var(--success-strong); }              /* contador de não lidas */

/* 2.4 — MARCA COMO TEXTO SOBRE A SUPERFÍCIE. Era 2,48:1 sobre #fff e 2,36:1 sobre #F6FAFB. */
.theme-a11y .tr-team,
.theme-a11y .conv-agent,
.theme-a11y .canned-item code,
.theme-a11y .rb-autor,
.theme-a11y .ctx-quick a,
.theme-a11y .etq-drop-nova,
.theme-a11y .etq-drop-item .mdi-check,
.theme-a11y .fp-add,
.theme-a11y .rel-item-msg,
.theme-a11y .list-tools button.tool-on { color: var(--brand-fg); }
/* ⚠️ O HOVER PRECISA DE REGRA PRÓPRIA: a folha do inbox declara a cor DE NOVO no hover, e sem
   repetir aqui o ponteiro em cima devolveria o #15B5C6 que a etapa acabou de tirar.
   ⚠️ E PRECISA DA GUARDA DE PONTEIRO. A capacidade `interface/identidade-e-estado` proíbe
   `:hover` solto, e a primeira versão destas três linhas caiu no arnês dela: num aparelho de
   toque, `:hover` fica GRUDADO depois do toque e o estado passa a mentir. `@media` não
   acrescenta especificidade, então envolver no lugar preserva a ordem da cascata. */
@media (hover: hover) and (pointer: fine) {
    .theme-a11y .fp-add:hover,
    .theme-a11y .rel-item:hover .rel-name { color: var(--brand-fg); }
}
/* Aba ativa: o texto E o sublinhado. O briefing permitia manter `--brand` no sublinhado se ele
   tivesse 3:1 com o fundo — tem 2,48:1, então vai para a variante de texto. */
.theme-a11y .inbox-tab.active,
.theme-a11y .vinc-tab.active { color: var(--brand-fg); border-bottom-color: var(--brand-fg); }
/* Contorno + texto na mesma peça. */
.theme-a11y .btn-abrir-ticket { color: var(--brand-fg); border-color: var(--brand-fg); }
@media (hover: hover) and (pointer: fine) {
    .theme-a11y .add-label:hover { color: var(--brand-fg); border-color: var(--brand-fg); }
}

/* 2.5 — TEXTO SOBRE TINTA DE MARCA. A tinta baixa o contraste, e por isso o token é outro:
   `--brand-fg` daria 4,42:1 sobre 12% de #15B5C6, e `--brand-on-tint` dá 5,27:1. */
.theme-a11y .status-pill { color: var(--brand-on-tint); }               /* 2,22:1 → 5,27:1 */

/* 2.6 — CHIPS E SELOS SOBRE TINTA. */
.theme-a11y .chip-success { color: var(--ok-strong); }                  /* 1,78:1 → 4,75:1 */
.theme-a11y .chip-info { color: var(--info-fg); }                       /* 2,21:1 → 4,80:1 */
.theme-a11y .tk-badge.tk-running { color: var(--ok-strong); }           /* 1,84:1 → 4,91:1 */
.theme-a11y .tk-play,
.theme-a11y .tk-run { color: var(--ok-strong); }

/* 2.7 — INDICADORES DE ESTADO (1.4.11, mínimo 3:1). Não são enfeite: dizem se a conexão está
   de pé e qual conversa está aberta. Se não se distinguem do fundo, a informação não existe. */
.theme-a11y .conn-dot.on { background: var(--ok-strong); }              /* 2,02:1 → 5,40:1 */
.theme-a11y .conv-mini.active::before { background: var(--brand-fg); }  /* 2,48:1 → 4,93:1 */
.theme-a11y .conv.active { box-shadow: inset 3px 0 0 var(--brand-fg); }
.theme-a11y .reuse-item.reuse-sugerido { border-color: var(--ok-strong); }

/* 2.8 — TÍTULO DE SEÇÃO DO TRILHO. 3,13:1 no trilho claro (#0F2830) e 3,80:1 no escuro
   (#0a1417) — reprova nos dois. `--rail-cap` dá 5,18:1 e 6,29:1, e segue abaixo do item de
   menu (#9fbac1, 7,51:1), preservando a hierarquia que igualar as duas cores apagaria. */
.theme-a11y .ez-rail .cap { color: var(--rail-cap); }

/* 2.9 — AVATARES DE INICIAIS BRANCAS.
   ⚠️ AS DEZOITO CORES REPROVAM HOJE: 9 das 10 do inbox (pior caso #ffc35a, 1,59:1) e 8 das 8
   do chat interno (pior 2,48:1). A cor vem INLINE do JavaScript, uma por semente de nome, e
   é por isso que o conserto não é trocar a cor: qualquer regra de `background` achataria as
   dezoito numa só, e o briefing pede "mantendo cores distintas entre si".

   A saída medida é um véu preto por CIMA da cor inline, via `background-image` — propriedade
   diferente de `background-color`, então o véu escurece sem apagar a matiz. A 45% o pior caso
   vira 4,92:1 (inbox) e 6,86:1 (chat), e as 18 seguem distintas duas a duas.

   `!important` é obrigatório: o `background` inline é shorthand e zera `background-image`, e
   declaração de folha só vence estilo inline com `!important`.

   `[style*=background]` limita a regra a quem TEM cor inline — sem isso, um avatar sem cor
   ganharia um disco cinza-escuro vindo do nada.
   ⚠️ A saída óbvia (iniciais escuras) foi MEDIDA E RECUSADA: não existe uma cor escura que
   passe nas dez do inbox. O melhor caso, preto puro, para em 3,84:1 sobre #6b5eae. */
.theme-a11y .av-ini[style*="background"],
.theme-a11y .ci-av-ini[style*="background"] {
    background-image: linear-gradient(rgba(0, 0, 0, .45), rgba(0, 0, 0, .45)) !important;
}

/* 2.10 — CONTORNO DE CONTROLE (1.4.11, mínimo 3:1).
   `--border` dá 1,23:1 e o `--nano-border-color` do vendor dá 1,64:1: um campo de texto vazio
   não tem limite visível. A regra alcança só CONTROLE — campo, seletor, área de texto. Os
   divisores de painel (`.col-list`, `.col-ctx`) seguem com `--border`, porque separar região
   não é componente de interface e escurecê-los mudaria o desenho da tela. */
.theme-a11y .ezinput,
.theme-a11y .form-control,
.theme-a11y .form-select,
.theme-a11y .comp-input,
.theme-a11y .search-input,
.theme-a11y .etq-drop-busca { border-color: var(--control-border); }

/* 2.11 — O CHAT INTERNO DA EQUIPE, que o briefing não citava e tinha OS SETE pares reprovando.
   ⚠️ ACHADO NA ETAPA 3, medindo tipografia. O briefing descreveu a tela de Atendimento; o chat
   da equipe (o offcanvas) repete os MESMOS componentes com outros nomes — bolha de saída,
   contador de não lidas, horário na bolha — e por isso ficou fora da lista. Medido em 29/09:

     bolha de saída (#fff sobre --ci-out #15B5C6)     2,48:1   ← o mesmo defeito do WhatsApp
     horário na bolha de saída (#eaffff a 90%)        2,20:1
     contador de não lidas (#fff sobre #17B26A)       2,76:1
     checks de "lida" (#a6ecf2 sobre #15B5C6)         1,88:1
     presença disponível (#17B26A)                    2,76:1
     presença ausente (#F79009)                       2,35:1
     presença desconectado (#CDD8DC / #3a4a50)  1,45:1 / 1,75:1

   É a lição da série repetida por escrito: rede que mede metade da superfície devolve metade do
   número. A folha `chat-interno.css` declara `:root` próprio e o arnês só lia o do tema. */
.theme-a11y {
    --ci-out: var(--brand-solido);        /* 2,48:1 → 4,93:1. Os checks `--ci-read` (#a6ecf2)
                                             passam a dar 3,74:1 sobre ele, acima do 3:1 do
                                             1.4.11 — não precisaram de regra. */
    --ci-pres-on: var(--ok-strong);       /* 2,76:1 → 5,40:1 claro / 7,80:1 escuro */
    --ci-pres-away: var(--warn-strong);   /* 2,35:1 → 4,73:1 claro / 10,07:1 escuro */
    /* ⚠️ Uma declaração só cobre os DOIS temas aqui, e de propósito: `--control-border` tem
       valor único (3,42:1 no claro, 4,73:1 no escuro), e `.theme-a11y` vence o
       `[data-theme=dark]` de `chat-interno.css` por ordem de origem. O ponto de desconectado
       era o pior par da folha: 1,45:1 no claro e 1,75:1 no escuro. */
    --ci-pres-off: var(--control-border);
}
/* ⚠️ O CONTADOR NÃO PODE USAR `--ci-pres-on`: ele carrega texto BRANCO, e `--ok-strong` clareia
   no tema escuro (#3CCB8E, branco a 2,07:1). Mesma separação de papéis do botão "Resolver". */
.theme-a11y .ci-unread { background: var(--success-strong); }           /* 2,76:1 → 5,40:1 */
/* O horário na bolha de saída: `#eaffff` a 90% dá 4,18:1 mesmo sobre o fundo novo. Branco opaco
   dá 4,93:1 — e a hierarquia continua, porque o texto da bolha é 600 e este é 400 a .62rem. */
.theme-a11y .ci-row.out .ci-meta { color: #fff; opacity: 1; }           /* 2,20:1 → 4,93:1 */

/* ── ETAPA 3 — TIPOGRAFIA ─────────────────────────────────────────────────────────────────────
   FAMÍLIA E CARREGAMENTO: NÃO HAVIA DEFEITO, e isso foi verificado em vez de suposto. A URL do
   Google Fonts já traz `&display=swap` nos dois layouts, a pilha do produto é
   `"Poppins", system-ui, sans-serif` e a do tema de terceiro é `--nano-font-sans-serif`: não há
   reserva serifada em caminho nenhum. O bloco 7 do arnês passou a cobrar as três coisas, para
   que a ausência de defeito não dependa de ninguém lembrar.

   O QUE FALTAVA ERA `tabular-nums`. Sem ele a fonte usa dígitos de largura variável, e numa
   lista de conversas que se atualiza sozinha o horário MUDA DE LARGURA a cada minuto — o texto
   ao lado dança. O produto já usava a propriedade em três lugares (`.rec-time`, `.tk-timer`,
   `.ez-num`), então aqui é estender um padrão que existe, não inventar um. */
.theme-a11y .conv-time,
.theme-a11y .note-time,
.theme-a11y .b-meta,
.theme-a11y .unread,
.theme-a11y .ez-rail a .b,
.theme-a11y .ci-meta,
.theme-a11y .ci-unread,
.theme-a11y .ci-day span { font-variant-numeric: tabular-nums; }

/* ⚠️ E UM PAR DE COR QUE AINDA REPROVAVA, achado aqui: o horário DENTRO da bolha de saída do
   WhatsApp. `#eaf3ff` com `opacity:.75` dava 1,81:1 sobre a bolha antiga — e mesmo sobre a
   bolha corrigida da Etapa 2 fica em 3,18:1, porque a opacidade come o ganho. Branco opaco dá
   4,93:1. O horário da bolha de ENTRADA não precisa de regra: herda `--ink` a 75% e já dá
   7,22:1 no claro e 8,26:1 no escuro. */
.theme-a11y .row-msg.out .b-meta { color: #fff; opacity: 1; }           /* 1,81:1 → 4,93:1 */

/* ── ETAPA 4 (grupo A) — FOCO, ALVOS E O QUE NÃO PODE FICAR ESCONDIDO ─────────────────────────

   2.4.7 — FOCO VISÍVEL: JÁ ESTAVA DE PÉ, e isso foi medido antes de mexer. `exizap-internas.css`
   declara `outline:2px solid var(--brand-strong) !important` para `a, button, input, select,
   textarea, [tabindex]` dentro de `.ez-int` — e o `!important` é o que faz os SEIS `outline:none`
   das folhas de página (`.comp-input:focus`, `.search-input:focus`, `.etq-drop-busca:focus`,
   `.ci-search input:focus`, `.ezinput:focus`, `.hist-busca input`) não apagarem nada, mesmo os
   que carregam DEPOIS da camada. O trilho escuro tem variante própria (`--c-300`, 8,22:1 sobre
   ele) e o toast também (branco, porque o anel de marca sobre `#fa5c7c` mede 1,42:1).

   ⚠️ MAS A FLAG PIORAVA O ANEL NO ESCURO, e este bloco existe por isso. O anel lê
   `--brand-strong`, que a Etapa 1 mudou de `#0C8695` para `#0e7c88`: sobre `#122329` isso cai de
   3,74:1 para 3,28:1. Continua acima do mínimo de 3:1 do 1.4.11, mas PIORA — e a regra da branch
   é que a flag não regride nada. `--brand-fg` tem par claro/escuro e melhora os dois: 4,93:1 no
   claro e 6,51:1 no escuro.

   ⚠️ `.ez-int.theme-a11y` E NÃO `.theme-a11y .ez-int`: as duas classes moram no MESMO elemento
   (o `<body>`), então a forma com espaço pede que uma seja descendente da outra e nunca casa. */
/* ⚠️ AQUI HAVIA UM OVERRIDE DA COR DO ANEL, E A CORREÇÃO DE PAPEL O TORNOU REDUNDANTE.
   Enquanto `--brand-strong` era fundo fixo (#0e7c88), o anel caía para 3,28:1 no escuro e
   precisava de `--brand-fg` por cima. Agora `--brand-strong` é a faixa de TEXTO e já clareia
   sozinho no escuro (#15B5C6): o anel dá 4,93:1 no claro e 6,51:1 no escuro sem regra nenhuma
   desta camada. Duas linhas que diziam o mesmo que o token já dizia saíram — a mutação que
   as apagava passou a ESCAPAR, e foi assim que a redundância apareceu.
   O bloco 8c-bis do arnês continua cobrando que a flag não piore o anel. */
/* O trilho e o toast mantêm as variantes deles — só reafirmadas, porque a regra acima tem
   especificidade maior que as originais e as engoliria. */
.ez-int.theme-a11y .ez-rail a:focus-visible { outline-color: var(--c-300) !important; }
/* ⚠️ O ANEL BRANCO DO TOAST ESTAVA ERRADO, E O COMENTÁRIO NO REPOSITÓRIO AFIRMAVA O CONTRÁRIO.
   `exizap-internas.css` diz, sobre o anel do toast: "Branco sobre os dois fundos passa". Medido
   agora: branco sobre o toast VERMELHO (#fa5c7c) dá 3,05:1 e passa; sobre o toast VERDE
   (#0acf97) dá 2,02:1 e REPROVA. A sessão que escreveu aquela nota mediu um fundo e concluiu
   pelos dois — exatamente o erro que a série inteira repetiu com cor.

   `--c-ink` (#0F2830) serve aos dois: 5,04:1 no vermelho e 7,60:1 no verde. E não é matiz nova
   — é o tom mais escuro da própria escala da marca, e não é redefinido no tema escuro, então o
   número vale nos dois. */
.ez-int.theme-a11y .toastify button:focus-visible,
.ez-int.theme-a11y .toastify a:focus-visible,
.ez-int.theme-a11y .toast-close:focus-visible { outline-color: var(--c-ink) !important; }

/* 2.5.8 — ALVO DE 24×24 CSS px.
   ⚠️ CRESCE A CAIXA, NÃO O ÍCONE: `min-width`/`min-height` mais centralização por flex. O glifo
   fica do mesmo tamanho e no mesmo lugar; só a área que recebe o dedo aumenta.

   ⚠️ E NÃO POR PSEUDO-ELEMENTO SOBREPOSTO, que é a saída óbvia e já deu defeito AQUI: o commit
   `ede4482b` registra "o vão entre ícones virou área do Excluir". Véu absoluto centralizado em
   ícones vizinhos se sobrepõe, e o clique vai para o errado. Caixa própria nunca invade o irmão.

   Medido no CSS (raiz de 16px), altura efetiva:
     .conv-act            16px   (font 1rem, line-height 1, padding 0 2px)
     .msg-act             16px
     .add-label        ~15px   (font .7rem + borda)
     .list-tools button ~21px
     .comp-tools button ~22px   ⚠️ e o vão de `.comp-tools` é .35rem = 5,6px: centro a centro dá
                                23,6px, ABAIXO de 24 — então nem a exceção de espaçamento salva
     .ez-top .ez-tico     20px   (o vão do topbar é 14px, centro a centro 34px: a exceção de
                                espaçamento cobriria, mas crescer aqui não tem risco de layout
                                porque a barra tem 66px de altura)
     .ez-railtoggle       22px */
.theme-a11y .conv-act,
.theme-a11y .msg-act,
.theme-a11y .list-tools button,
.theme-a11y .comp-tools button,
.theme-a11y .add-label,
.theme-a11y .ez-top .ez-tico,
.theme-a11y .ez-railtoggle {
    min-width: 24px;
    min-height: 24px;
    display: inline-flex;
    align-items: center;
    justify-content: center;
}
/* ⚠️ `.msg-act` é `position:absolute` no canto da bolha, e crescer para 24×24 faz a caixa
   TRANSPARENTE cobrir o canto do texto. O texto da bolha não é clicável, então nada de clique se
   perde; o que se perde é seleção de texto nesse canto de 24px. É o custo consciente de a ação
   ter alvo alcançável, e o briefing pede exatamente "aumentar a área clicável sem alterar o
   tamanho visual do ícone". */

/* 44×44 em "Enviar" e "Resolver" — o RECOMENDADO do briefing, não o exigido (a AA pede 24, e os
   dois já davam ~30px). São as duas ações mais repetidas do dia de um atendente.
   ⚠️ ESTA É A ÚNICA MUDANÇA DE APARÊNCIA DELIBERADA DA ETAPA: os dois botões ficam mais altos,
   e isso muda a altura do compositor e do cabeçalho da conversa. Fica dentro da flag e vai para
   conferência na Etapa 7, com a tela aberta. */
.theme-a11y .btn-send,
.theme-a11y .btn-resolve {
    min-height: 44px;
    min-width: 44px;
    display: inline-flex;
    align-items: center;
    justify-content: center;
}

/* 2.4.11 — O FOCO NÃO PODE FICAR ESCONDIDO.
   O layout já protege quase tudo: `.ez-top` NÃO é sticky (é irmão flex com `flex-shrink:0`, e
   quem rola é `.ez-content`), então não existe cabeçalho fixo passando por cima do conteúdo
   rolado. O único `position:sticky` das nossas folhas é `.ci-emoji-tabs`, dentro do seletor de
   emoji do chat — um emoji focado por teclado rola para debaixo das abas. `scroll-margin-top`
   faz a rolagem parar antes. */
.theme-a11y .ci-emoji-pop button { scroll-margin-top: 36px; }

/* ── ETAPA 6 — MOVIMENTO CONTIDO ──────────────────────────────────────────────────────────────

   AUDITORIA PRIMEIRO, medida nas sete folhas nossas:

     transição por propriedade  transform(9) background-color(5) color(5) box-shadow(3)
                                opacity(3) background(1) border-color(1) visibility(1)
                                max-height(1) width(1)
     durações declaradas        60ms(1) 150ms(2) 200ms(4) 220ms(1) 250ms(2) — nenhuma > 400ms
     animações infinitas        3

   AS TRÊS INFINITAS ESTÃO CERTAS, e a conta de 2.3.1 fecha nas três (período ≥ 1,1 s, ou seja
   menos de 1 piscada por segundo, contra o limite de 3):
     · `.ci-typing-b span` — o indicador de "digitando", que o briefing PERMITE por nome;
     · `.bk-slot[data-ez-esperando]` — o indicador de carregando, que o spec manda NÃO congelar
       (tela parada é pior que tela que se mexe);
     · `.rec-dot` — a gravação de áudio em curso. Não é selo pulsando por enfeite: é o único
       sinal de que o microfone está aberto.
   `identidade-e-estado.test.js` já cobra as três com exceção nomeada — não se repete aqui.

   ⚠️ O QUE ESTAVA ERRADO: QUATRO `:hover` DESLOCAM O PRÓPRIO ALVO, e o briefing proíbe isso duas
   vezes ("botões magnéticos ou efeitos que desloquem alvos" e "animação que desloque o item da
   lista sob o cursor"). Dois deles são AÇÃO DE LINHA — o Editar e o Excluir de toda lista do
   produto, que crescem 12% quando o ponteiro chega. Num alvo de 24px isso muda a borda da área
   clicável no meio da mira, e quem tem tremor ou usa trackpad paga por isso.

   Removê-los não deixa o botão sem resposta: `exizap-theme.css` já muda a COR no hover
   (`.ez-table .acts i:hover`), `.react-emoji` já muda o fundo, e `.bk-slot` já revela um traço
   por `::after` — realimentação que não move nada.

   ⚠️ `:active` FICA. Ele também escala (`scale(.88)`), mas acontece DEPOIS de o clique pousar:
   não há como errar a mira por causa dele. O que o briefing proíbe é o alvo fugir enquanto se
   aponta, e isso é `:hover`. */
@media (hover: hover) and (pointer: fine) {
    .ez-int.theme-a11y .ez-table button[data-act]:not([class]):hover,
    .ez-int.theme-a11y .ez-table button[data-a]:not([class]):hover,
    .ez-int.theme-a11y .ez-table .acts > i:hover,
    .theme-a11y .react-emoji:hover,
    /* ⚠️ `.ez-pub`, E NÃO `.ez-sup`. A primeira versão desta linha usou `.ez-sup.theme-a11y` e
       ficou INERTE: `exizap-publicas.css` escopa `.bk-slot` sob `.ez-pub`, e as quatro telas de
       agendamento/exames trazem `<body class="ez-sup ez-pub">`. O arnês pegou, e o rastro levou
       a um achado maior — essas quatro páginas têm `Layout = null` e `<body>` próprio, então
       nem carregavam esta folha. Ver o comentário que elas ganharam. */
    .ez-pub.theme-a11y .bk-slot:hover { transform: none; }

    /* ⚠️ E A COR DE HOVER DELES REPROVAVA. `exizap-theme.css` usa `var(--brand)` (#15B5C6) no
       hover do ícone de ação: 2,48:1 sobre branco. O ícone em repouso é `--muted`, que a Etapa 1
       levou a 4,93:1 — então passar o mouse DEIXAVA O ÍCONE MENOS VISÍVEL do que parado. */
    .ez-int.theme-a11y .ez-table .acts i:hover { color: var(--brand-fg); }   /* 2,48:1 → 4,93:1 */
}

/* A faixa que o briefing permite para hover, foco, dropdown, modal e painel é 120–200 ms.
   `--mo-painel` é 250 ms (a superfície que atravessa a tela, o trilho off-canvas). 200 ms fecha
   a faixa e a diferença é imperceptível; o token existe justamente para essa troca ser de uma
   linha. Os outros três (`--mo-toque` 60 ms, `--mo-rapido` 150 ms, `--mo-abre` 200 ms) já estão
   dentro — 60 ms é o "afundou" de um botão, mais curto que a faixa de propósito. */
.theme-a11y { --mo-painel: 200ms; }

/* ── ETAPA 7 — O QUE SÓ A TELA ABERTA MOSTROU ─────────────────────────────────────────────────
   Os dez blocos de arnês estático leem o que o CSS DECLARA. Estes dois defeitos não estavam em
   declaração nenhuma que eu soubesse procurar — apareceram medindo `getComputedStyle` na página
   montada, com o Chrome, no /Crm/Clientes. É a diferença entre bancada e tela.

   ⚠️ 1. `.ezbtn-primary` É O BOTÃO PRIMÁRIO DE TODO O PRODUTO, e reprovava: `background:
   var(--brand)` com `color:#fff` dá 2,48:1. Ele está em praticamente toda tela — "Novo cliente",
   "Novo documento", "Salvar" — e passou por três etapas de auditoria de cor sem eu vê-lo, porque
   eu tinha ido atrás dos componentes que o briefing NOMEAVA (os do inbox) e não dos que o
   produto repete em todo lugar. O briefing listou a tela de Atendimento; o botão primário mora
   no tema.

   O hover dele também reprova: `var(--c-600)` (#0C96A6) dá 3,54:1. `--c-800` (#10646E) dá
   6,84:1 e é o degrau seguinte da MESMA escala da marca — não é matiz nova.

   `.ezbtn-bright` foi medido e está CERTO: `--c-900` sobre `--brand-bright` dá 6,24:1. Fica
   como está. */
.theme-a11y .ezbtn-primary {
    background: var(--brand-solido);                  /* 2,48:1 → 4,93:1 */
    /* A sombra herdava `--brand` e ficava mais clara que o botão; segue a cor do fundo. */
    box-shadow: 0 8px 20px -8px var(--brand-solido);
}
@media (hover: hover) and (pointer: fine) {
    .theme-a11y .ezbtn-primary:hover { background: var(--c-800); }   /* 3,54:1 → 6,84:1 */
}

/* ⚠️ 2. A LINHA INATIVA DESAPARECIA, E POR MULTIPLICAÇÃO. `.ez-table .off td{ opacity:.55 }`
   marca cliente/contato desligado — e `opacity` multiplica o que já é fraco: o texto da célula é
   `--muted`, que a Etapa 1 levou a 4,93:1, e a 55% ele volta para 2,15:1. Pior que antes da
   camada. Medido na tela: 2,36:1 e 3,76:1 em células reais do /Crm/Clientes.

   Nenhum arnês estático veria isto: `opacity` não é propriedade de cor, e o valor declarado em
   `color` continua sendo o certo. Só a página montada mostra o resultado.

   A saída é dizer a cor em vez de diluí-la: opaco em `--muted` dá 4,93:1 no claro e 6,09:1 no
   escuro, e a linha continua LENDO como desligada, porque a ativa usa `--ink` (16,5:1). A
   diferença de peso entre as duas segue enorme; o que muda é que a desligada agora se lê. */
.theme-a11y .ez-table .off td {
    opacity: 1;
    color: var(--muted);
}

/* ── ETAPA 7, SEGUNDA RODADA — 44 TELAS ABERTAS NO CHROME ─────────────────────────────────────
   Medido: 669 falhas de contraste no tema claro com a flag desligada, 80 com ela ligada. Estes
   80 eram de treze seletores que nenhum dos dez blocos estáticos podia ver, e por UM motivo
   estrutural:

   ⚠️ O ARNÊS LÊ 7 ARQUIVOS DE CSS. O PRODUTO TEM 59 FONTES. Cinquenta e duas páginas `.cshtml`
   trazem bloco `<style>` próprio — 8.361 linhas de CSS que vivem dentro do markup. `.lead-chip`,
   `.ag-views button.active`, `#rRest.ok` e as regras do calendário estão todas lá. A camada
   alcança essas regras porque `.theme-a11y X` tem especificidade maior que `X`; o que não
   alcançava era o TESTE.

   ⚠️ E UM ACHADO DE CASCATA QUE VALE PARA TODA A CAMADA: `--inbox-muted: var(--muted)` é
   declarado em `:root`, e `var()` ali é resolvido COM O VALOR DE `:root`. A flag põe `--muted`
   no `<body>` — um nível abaixo —, então o token DERIVADO continuava com o valor antigo
   (#7B8E95, 3,42:1) enquanto o token de origem já estava corrigido. Medido em `.inbox-tab` e
   `.list-empty`. Todo token derivado de um token que a flag sobrescreve precisa ser re-derivado
   aqui, e o bloco 11 do arnês passou a cobrar isso. */
.theme-a11y {
    /* Re-derivação: mesmo texto da declaração original, resolvido agora no `<body>`. */
    --inbox-muted: var(--muted);
    --ci-muted: var(--muted);

    /* ⚠️ `--card` É LIDO CINCO VEZES E NUNCA FOI DEFINIDO. As cinco leituras são
       `var(--card,#fff)` — então todas caem no branco de reserva, NOS DOIS TEMAS, e o cartão
       fica branco enquanto o texto dele clareia no escuro. Medido: `--ink` escuro (#e6eef0)
       sobre #fff dá 1,20:1 em quatro KPIs do /Relatorios, e `--muted` escuro (#8aa3aa) dá
       1,97:1. É exatamente o padrão que o `exizap-theme.css` registra sobre `--success`: token
       que existe como LEITURA e não como definição, com cada uso caindo na reserva escrita ao
       lado dele. Definir o token aqui conserta os cinco de uma vez. */
    --card: var(--surface);

    /* ⚠️ E `--card` NÃO ESTAVA SOZINHO. Varrendo as 52 páginas e as 7 folhas, oito tokens
       são LIDOS com valor de reserva e nunca DEFINIDOS em lugar nenhum — nem nas nossas
       folhas, nem no tema de terceiro. Toda leitura cai na reserva, que foi escrita para o
       tema CLARO, e por isso a caixa continua clara no escuro com texto claro em cima.
       Medido: `.ag-aviso` (Comercial/Agente) fica `#fafafa` com `--ink` escuro (#e6eef0)
       por cima — 1,15:1. Os quatro abaixo são os que afetam contraste; os outros quatro
       (`--ez-mx`, `--ez-my`, `--shadow-sm`, `--bs-border-color`) são medida e sombra, e o
       bloco 12 do arnês os lista com esse motivo. */
    --ez-bg-muted: var(--bg);
    --ez-border: var(--border);
    --ez-primary: var(--brand-strong);
    --inbox-hover: rgba(21, 181, 198, .1);   /* igual à reserva: tinta de hover, não carrega texto */

    /* ⚠️ TINTA MORNA PEDE ÂMBAR MAIS ESCURO. `--warn-strong` (#9a6a00) passa sobre branco
       (4,73:1) e REPROVA sobre a tinta de aviso (#f7f3de): 4,25:1. Mesmo motivo do
       `--brand-on-tint`: a tinta come contraste, e o token do papel é outro. */
    --warn-on-tint: #7d5600;      /* 5,88:1 sobre #f7f3de e 6,56:1 sobre branco */
}

/* O botão primário do TEMA DE TERCEIRO, que é outro do `.ezbtn-primary` nosso. Branco sobre
   `--nano-primary` (#2c8ef8) dá 3,32:1, e ele aparece em 8 das 44 telas (o "Go Back" das telas
   de estado). `--primary-fg` (#0b5ed7) dá 5,84:1 e é a mesma matiz escurecida. */
.theme-a11y .btn-primary {
    background-color: var(--primary-solido);
    border-color: var(--primary-solido);
}

/* Texto de marca sobre tinta clara de marca. `--brand-strong` dá 4,45:1 sobre `--info-soft` —
   reprova por 0,05 — e `--brand-on-tint` dá 5,31:1. `.ezbadge` está no tema; `.lead-chip` vive
   no `<style>` de três páginas de Campanhas. */
.theme-a11y .ezbadge,
.theme-a11y .lead-chip { color: var(--brand-on-tint); }

/* Branco sobre `--brand` em peça de página: o chip ligado das Campanhas e o seletor de visão da
   Agenda. Mesmo 2,48:1 da bolha de saída. */
/* ⚠️ `color:#fff` AQUI NÃO É REDUNDANTE, É O CONSERTO DE UMA REGRESSÃO QUE EU CAUSEI. A regra de
   cima pinta `.lead-chip` com `--brand-on-tint` (texto escuro, para o chip de fundo claro), e o
   chip LIGADO tem fundo escuro. A minha regra de cor tem especificidade (0,2,0) e carrega DEPOIS
   da folha da página, então ela vencia o `color:#fff` que o `.lead-chip.on` já declarava: o
   resultado medido foi #0b6f7a sobre #0e7c88 — 1,19:1, o pior par da branch, e criado por mim.
   A varredura das 44 telas pegou; nenhum arnês estático pegaria, porque as duas regras estão
   certas isoladamente e o defeito é a interação. */
.theme-a11y .lead-chip.on,
.theme-a11y .ag-views button.active {
    background: var(--brand-solido);
    box-shadow: 0 4px 12px -6px var(--brand-solido);
    color: #fff;                        /* 4,93:1 sobre --brand-solido */
}

/* O dia de HOJE no calendário: `var(--brand)` em negrito sobre `--bg` dá 2,32:1. É a marca como
   TEXTO, que é o papel que ela não serve.
   ⚠️ `#calendar` NO SELETOR, e não é enfeite: a regra da página é
   `#calendar .fc-day-today .fc-daygrid-day-number`, com ID. Especificidade de ID vence qualquer
   quantidade de classe — a primeira versão desta linha usava só `.theme-a11y .fc-day-today …`
   e ficou inerte. A varredura pegou: dois dias "30" seguiram em 2,32:1. */
.theme-a11y #calendar .fc-day-today .fc-daygrid-day-number { color: var(--brand-fg); }

/* `<code>` de variável de modelo ("{setor}", "{link}") em Triagem e Avaliação: `--nano-info`
   (#39afd1) sobre branco dá 2,55:1. */
.theme-a11y code { color: var(--info-fg); }

/* O verde literal que sobrou de antes dos tokens: #0a8f5e dá 4,11:1. Os outros dois literais
   verdes das páginas foram medidos e PASSAM (#1a7a45 dá 5,37:1 e #1a7f45 dá 5,04:1), então
   ficam como estão. */
.theme-a11y #rRest.ok { color: var(--ok-strong); }

/* ⚠️ O CALENDÁRIO DIMINUÍA O DIA COM `opacity`, e é o mesmo defeito da linha inativa: o
   FullCalendar apaga o dia de fora do mês com opacidade própria, e sobre `--muted` isso desce
   para 1,50:1 — o pior par medido nas 44 telas. Dia de outro mês é clicável, então é conteúdo,
   não enfeite. Cor explícita em vez de diluição. */
.theme-a11y .fc .fc-day-other .fc-daygrid-day-number,
.theme-a11y .fc .fc-day-other .fc-daygrid-day-top { opacity: 1; color: var(--muted); }
/* ⚠️ NO ESCURO O FUNDO DESSA CÉLULA NÃO É A SUPERFÍCIE DA PÁGINA. O FullCalendar pinta o dia
   de fora do mês com cinza próprio — medido `#323b46` —, e sobre ele `--muted` escuro
   (#8aa3aa) dá 4,27:1: reprova por 0,23. `#a3b6bc` dá 5,39:1 e segue mais apagado que o dia
   do mês corrente, que usa `--ink` (#e6eef0). Um valor por tema porque o FUNDO muda de
   polaridade, que é a mesma razão de todos os pares desta folha. */
[data-theme=dark] .theme-a11y .fc .fc-day-other .fc-daygrid-day-number,
[data-theme=dark] .theme-a11y .fc .fc-day-other .fc-daygrid-day-top { color: #a3b6bc; }

/* O aviso do Consentimento traz `color:#6b4a00` LITERAL, e o fundo dele é `--warn-soft`, que
   no escuro vira tinta escura: o marrom fixo dá 1,7:1 ali. `--warn-on-tint` tem o par. */
.theme-a11y .cs-aviso { color: var(--warn-on-tint); }

/* O aviso de "caixas sem membros" da tela de Conexões, que é o único uso de texto âmbar sobre
   tinta âmbar no produto: `#caixasAviso` traz `background:rgba(255,193,7,.12)` e
   `color:var(--warn-strong)` inline, o que compõe 4,25:1 sobre a tinta.
   ⚠️ `!important` OBRIGATÓRIO: a cor vem de atributo `style` inline, e declaração de folha só
   vence estilo inline com ele. Mesma justificativa dos avatares. */
.theme-a11y #caixasAviso { color: var(--warn-on-tint) !important; }   /* 4,25:1 → 5,88:1 */

/* ── ETAPA 7, COMPLEMENTO — A FAIXA DE MARCA COMO FUNDO SÓLIDO ────────────────────────────────
   ⚠️ SEIS INSTÂNCIAS DA MESMA CLASSE DE DEFEITO, em seis arquivos, todas escrevendo
   `background:var(--ok|--danger)` com `color:#fff`. É o uso que o `exizap-theme.css` proíbe por
   escrito: a faixa de marca serve fundo, borda e selo, e é clara de propósito — como fundo de
   texto BRANCO ela não passa. Medido: branco sobre `--danger` dá 3,76:1 e sobre `--ok` dá 2,76:1.

   Achado abrindo `/agendar/cancelar/{token}`, uma tela que ninguém nunca tinha aberto porque a
   rota exige um token de agendamento existente. O botão "Cancelar meu agendamento" — a ação
   DESTRUTIVA de uma página que o paciente usa sem login — estava em 3,76:1.

   DUAS DELAS SÃO PÚBLICAS (`Publico/Pedido` e `Publico/Proposta`), e continuam sem medição de
   tela: os tokens delas pedem pedido e proposta no banco, que é dado de outro módulo. Estão
   consertadas por token, não por medida — e isso está dito no relatório.

   `--danger-solido` nasce aqui pelo mesmo motivo de `--brand-solido` e `--primary-solido`:
   `--danger-strong` tem par claro/escuro (#B42318 / #FF9A8B) porque é faixa de TEXTO, e branco
   sobre o valor escuro dele dá 2,00:1. Fundo que carrega branco pede valor fixo. */
.theme-a11y {
    --danger-solido: #B42318;     /* branco sobre ele: 6,57:1, igual nos dois temas */
}

/* ⚠️ `!important` porque a cor vem de atributo `style` inline na .cshtml. */
.theme-a11y #btnCancelar { background: var(--danger-solido) !important; }   /* 3,76:1 → 6,57:1 */

/* Cronômetro de tarefa e de ticket: verde a correr, vermelho a parar. */
.theme-a11y .tk-timerbtn { background: var(--success-strong); }            /* 2,76:1 → 5,40:1 */
.theme-a11y .tk-timerbtn.on { background: var(--danger-solido); }          /* 3,76:1 → 6,57:1 */

/* "Concluir" do To-Do, sob o ponteiro. */
@media (hover: hover) and (pointer: fine) {
    .theme-a11y .td-act.ok:hover { background: var(--success-strong); }    /* 2,76:1 → 5,40:1 */
}

/* As duas telas PÚBLICAS: aprovar pedido e aceitar proposta. Ação afirmativa, texto branco. */
.theme-a11y .ap,
.theme-a11y .btn.accept {
    background: var(--success-strong);                                     /* 2,76:1 → 5,40:1 */
    box-shadow: 0 10px 24px -10px var(--success-strong);
}

/* ── ETAPA 7, TERCEIRO ACHADO — O CALENDÁRIO COM EVENTO DENTRO ────────────────────────────────
   ⚠️ ESTES QUATRO SÓ APARECERAM QUANDO O CALENDÁRIO TEVE EVENTO, e a varredura anterior mediu
   uma agenda VAZIA. O que criou o evento foi o próprio percurso das telas públicas
   (`acessibilidade-telas-publicas.mjs` confirma um agendamento para poder abrir a tela de
   cancelar) — o arnês sujou a tela e a medição seguinte achou o que estava lá desde sempre.
   É a mesma lição da série por outro caminho: tela sem dado não é tela medida.

   `#calendar` declara `--fc-event-text-color:#fff` e pinta o evento com a faixa de MARCA
   (`--brand`) ou com `--warn` no lembrete. Branco sobre `--brand` dá 2,48:1 e sobre `--warn` dá
   2,35:1; e no dia de HOJE, onde o evento não pinta fundo próprio, o branco caiu sobre a tinta
   clara do dia — 1,11:1, o pior par de toda a branch.

   `--warn-solido` nasce pelo mesmo motivo dos outros três `-solido`: `--warn-strong` tem par
   claro/escuro (#9a6a00 / #FFC24D) porque é faixa de TEXTO, e branco sobre o valor escuro dele
   dá 1,60:1. Fundo que carrega branco pede valor fixo nos dois temas. */
.theme-a11y {
    --warn-solido: #9a6a00;       /* branco sobre ele: 4,73:1, igual nos dois temas */
}

/* ⚠️ O ESCOPO É `#calendar` porque a regra de origem também é: ID vence classe, e sem ele o
   override fica inerte — o mesmo tropeço do dia de hoje, três blocos acima. */
.theme-a11y #calendar {
    --fc-event-bg-color: var(--brand-solido);      /* 2,48:1 → 4,93:1 */
    --fc-event-border-color: var(--brand-solido);
}
/* ⚠️ E O EVENTO PRECISA DE FUNDO PRÓPRIO SEMPRE. No dia de hoje o FullCalendar não pinta o fundo
   do evento e o texto branco caiu na tinta do dia (1,11:1). Declarar o fundo no `.fc-event`
   garante que o branco sempre tem sobre o que pousar. */
.theme-a11y #calendar .fc-event {
    background-color: var(--brand-solido);
    border-color: var(--brand-solido);
}
.theme-a11y #calendar .fc-lemb {
    --fc-event-bg-color: var(--warn-solido);       /* 2,35:1 → 4,73:1 */
    --fc-event-border-color: var(--warn-solido);
    background-color: var(--warn-solido);
    border-color: var(--warn-solido);
}
/* O "+2 mais" de um dia cheio: texto de marca sobre a tinta do dia, 4,45:1 — falta 0,05, e é
   exatamente o caso do `--brand-on-tint`. */
.theme-a11y #calendar .fc-daygrid-more-link { color: var(--brand-on-tint); }   /* 4,45:1 → 5,31:1 */
