fix(quality): drop two unnecessary any casts that leave the branch lint-red

[HouMinXi]

npm run lint exits 1 on release/v3.8.50 with nothing checked out on top of it:

$ git worktree add <tmp> --detach upstream/release/v3.8.50   # 2cb7567d6, no edits
$ npm run lint
tests/unit/issue-9407-gemini-web-validation-false-positive.test.ts
  50:38  error  Unexpected any. Specify a different type  @typescript-eslint/no-explicit-any
tests/unit/v1-models-auth-leak-9320.test.ts
  83:54  error  Unexpected any. Specify a different type  @typescript-eslint/no-explicit-any
2 problems (2 errors, 0 warnings)
(exit 1)

Both files arrived on 2026-08-04 with #9407 and #9320 and are absent from config/quality/eslint-suppressions.json, whose own most recent commit (3440c118e, #9205) is newer than both. So the branch fails its own gate, and every pull request opened against it inherits the failure regardless of what it changes. Two of mine opened today, touching no shared files, show the identical pair.

The fix

Neither cast was doing anything, so this removes them rather than freezing them.

GeminiWebExecutor declares testConnection as a public method (open-sse/executors/gemini-web.ts:359), so the test can read it directly. getApiKeys returns a typed view whose name field infers correctly in the find callback, so the parameter annotation was redundant.

Leaving config/quality/eslint-suppressions.json untouched is deliberate: the allowlist policy in CLAUDE.md asks for the cause to be fixed where it can be, and freezing these two would have carried them forward as permanent entries.

Verification

$ npm run lint
(exit 0)

$ npm run typecheck:core
(exit 0)

$ node --import tsx/esm --import ./open-sse/utils/setupPolyfill.ts \
    --import ./tests/_setup/isolateDataDir.ts --test --test-force-exit \
    tests/unit/issue-9407-gemini-web-validation-false-positive.test.ts \
    tests/unit/v1-models-auth-leak-9320.test.ts
# tests 12
# pass 12
# fail 0

Removing a cast can change what an assertion actually observes, so the #9320 lookup was re-pointed at a key name that does not exist to confirm the assertion still has teeth:

# tests 12
# pass 11
# fail 1

Restored, and green again.

What this does to CI, measured against a PR without it

The lint-guard job runs npm run lint:json -- --max-warnings 0 as its second step. Comparing that job across two of my PRs opened minutes apart against the same base, one carrying this change and one not:

                                        without this change   with it
ESLint (baseline congelado)             failure               success
Run npm run quality:collect             skipped               success
Ratchet check (blocking)                skipped               success
Require-tighten (blocking)              skipped               success
CodeQL alerts ratchet (blocking)        skipped               failure

So this is necessary but not sufficient. It clears the first gate; the job then reaches three more that were previously never evaluated, and stops at the CodeQL ratchet:

[codeql-ratchet] Alertas CodeQL abertos (nao-dismissed): 1
[codeql-ratchet]   Top regras: js/stack-trace-exposure(1)
[codeql-ratchet] REGRESSAO - 1 alertas CodeQL abertos > baseline 0

That one alert is repository-wide rather than per-PR, so it is red on every open pull request too. js/stack-trace-exposure is the rule CLAUDE.md Hard Rule #14 already documents as a known CodeQL limitation on call sites that route through sanitizeErrorMessage(), which suggests a dismissal rather than a code change, but that is your call and not something I would do unasked.

The neighbouring fast-gates job stops even earlier, at check:file-size:

[file-size] 2 violacoes:
  src/sse/handlers/chat.ts: 1846 > congelado 1845
  open-sse/executors/base.ts: 1623 > congelado 1578

Neither file is touched here.

Related

#8542 describes exactly the compounding this makes visible: with the ESLint step red, nothing downstream in that job ever ran, so the CodeQL regression was invisible in every PR log until the first gate was cleared. #8522 describes the same pattern from the baseline side. Both still open.

[HouMinXi]

#9488 cleared both casts, plus a third base-red in the translate-path snapshot that I had missed. Nothing left in this branch. Closing.