fix(ci): clear the release/v3.8.51 base-reds left by the 09-15 batch (stryker, CLI i18n, paid-target fixture, call-log traceId, Jina prefix, callLogStats import, gitleaks)

[diegosouzapw]

Why

Every PR into release/v3.8.51 pushed after #13635/#13678 still failed Fast Quality Gates and all four Unit Tests fast-path shards, on the same 16 tests (#13266, #13173, #13149, #13150, #13355, #13628, #13717 and #13720 fail on exactly this set). Each failure reproduces on the pure tip. All five come from yesterday's batch: none is a product defect, and no assertion is weakened.

Red	Root cause	Fix
FQG mutation-test-coverage	noauth-model-lockout and local-token-budget-429-skips-cooldown (#13606) cover accountFallback.ts / auth.ts / comboPredicates.ts, but neither is in stryker.conf.json tap.testFiles	add both entries
cli-i18n-catalog (1, then 2 parity)	--ready-timeout calls t("serve.ready_timeout") with no catalog entry	add the key to en, zh-CN, zh-TW (the parity-checked CLI locales)
paid-model-target-6540 (1) + paid-model-target-routes-6540 (3)	#13407 removed Together's one-time credit, so together/… now classifies as unknown, and the save-time guard correctly lets it through	the paid fixture is now gemini/gemini-3.1-pro-preview (Gemini's free tier recurs and does not include Pro), plus a precondition test that the fixtures still classify as paid/free/unknown
attempt-logging-early-keepalive-merge (3) + video-bridge-log-redaction (6, 30 s timeouts)	#13546 keys the call-log row on traceId, but these tests poll by pendingRequestId	baseCtx defaults traceId to pendingRequestId, the same pattern chatcore-attempt-logging got in #13546. The keepalive poll moves to the 30 s wall-clock deadline video-bridge already uses
API Route Typecheck + check:dashboard-typecheck	the #13641 merge left ERROR_TYPE_CONTRACT imported twice in src/lib/db/callLogStats.ts (TS2300)	drop the duplicate import
FQG secrets (ratchet 0 → 1)	the Uzbek catalog from #13727 translates outputTokenDesc as "Yakunlash/javob tokenlari", which generic-api-key reads as a token value	narrow regex allowlist entry in .gitleaks.toml, with the reason
dashboard-request-failed-redaction (1)	the probe reads the persisted row by pendingRequestId; since #13546 the row is keyed by traceId	read it by traceId (the two ids stay distinct, so the test still pins the key)
FQG file-size (PR mode)	#13748 grew image-generation-handler.test.ts 2133→2235 and #13749 grew batch_api.test.ts 1345→1348. PR mode does not relax testFrozen against the base	re-freeze both at the merged LOC, with a justification entry (same pattern as the 2026-09-02 base-red drain)
models-catalog-route Jina custom (1)	#13403 switched the custom-row assertion to jina/, but custom rows keep the connection's provider id (jina-ai/). Only synced rows go through the jina alias, and the test above covers those	restore jina-ai/ for custom rows

Refs #12732

Validation

On the merge with the tip (c8b24ffc). Rows 6–9 came from this PR's CI runs and were fixed in follow-up commits:

• node scripts/check/check-mutation-test-coverage.mjs --strict: no drift
• check-api-typecheck: FAIL before (callLogStats.ts TS2300), exit 0 after. check-secrets --ratchet: 0 findings. check:file-size --base-ref: OK.
• check-test-discovery, check-changelog-integrity: OK. ESLint (with suppressions) and Prettier are clean on the changed files. Pre-commit hooks ran green.
• node --test on each touched file, run in full: cli-i18n-catalog 11/11, paid-model-target-6540 10/10, paid-model-target-routes-6540 11/11, attempt-logging-early-keepalive-merge 4/4, video-bridge-log-redaction 7/7, models-catalog-route all pass. The covering tests noauth-model-lockout, local-token-budget-429-skips-cooldown and i18n-home-recent-requests-topology-legend also pass.
• Redaction probe, checked both directions: reading by pendingRequestId asserts null; reading by traceId prints the probe result. Locally the probe takes ~60 s at load ~45, past the test's 30 s cap; CI is fine.
• Checked both directions: with traceId removed from baseCtx, the keepalive merge test fails even with the 30 s deadline; with it restored, 4/4 pass.

Notes:

• chatcore-attempt-logging (not touched) can miss its 2.4 s poll on a heavily loaded machine: 2 failures at load average ~45 locally, 7/7 with a larger budget. It does not fail in CI, so it stays out of scope here.
• The custom-vs-synced Jina prefix mismatch (jina-ai/ vs jina/) is existing runtime behaviour. This PR only realigns the test; unifying the two prefixes would change user-visible model ids and belongs in its own change.

[diegosouzapw]

Confirmação independente e um dado que pode poupar uma caça a flake.

Cheguei às mesmas duas causas-raiz por conta própria, antes de ver esta PR — o que é boa validação dos consertos daqui:

• fixture do modelo pago: d6e62ae3 (fix(free-tiers): remove obsolete Together $25 signup credit (#12526) #13407) tirou a única entrada do Together no catálogo grátis, então providerHasFreeModels("together") virou false, isPaidModelTarget devolveu unknown e a rota falhou aberto por design.
• video-bridge: 97ae1017 (fix(resilience): winning failover attempt's call log dropped (call_logs.id UNIQUE clash) #13481) passou a chavear call_logs por traceId. Confirmei com sonda em arquivo dentro de saveCallLog (o console é engolido pelo runner do node:test): a função é chamada com persistência ligada e nunca lança — a entrada simplesmente chegava sem id.

Não vou abrir PR concorrente; esta chegou primeiro e cobre mais.

O dado novo: cold start do worker de artefato

Depois do conserto de traceId, um caso de video-bridge-log-redaction.test.ts continua sensível a carga: "persisted requestBody carries the placeholder and never the raw transcript when a redaction map is present". É o único que passa pelo caminho de artefato, e ele paga o cold start do worker no primeiro write.

Medido com timestamps dentro de saveCallLogOperation, carga do devbox em ~70:

A1 antes  de writeCallArtifactAsync   t=1517 ms
A2 depois de writeCallArtifactAsync   t=28789 ms   ← 27,3 s para um arquivo de 844 bytes
INSERT                                t=28789 ms
poll do teste                         30000 ms

Com carga ~70 passa por pouco; com ~107 estourou os 30 s e falhou isolado, de forma reproduzível. Não é defeito de lógica — o artefato é gravado e o insert acontece, só depois do prazo.

No CI da #13730 esse caso não apareceu entre as falhas deste arquivo (as de lá eram as de 30013/30018 ms, espera esgotada na chave errada), então provavelmente passa no runner. Se aparecer como flake, a correção de princípio é aquecer o writer no before(), para a espera medir a gravação e não o boot do worker — e não aumentar o prazo.