fix(ci): allowlist the published extension key by exact value

[abrichr]

Every capture pull request is failing Secret Scan, and main is stale-green

gitleaks reports one finding:

RULE   : generic-api-key
FILE   : chrome_extension/manifest.json
COMMIT : da50e6f2149b
BRANCH : rescue/codex/browser-observer-post-96-78c0be92

This is not introduced by any pull request. That commit is not an ancestor of any PR branch. secret-scan.yml runs gitleaks git . after a fetch-depth: 0 checkout, which reads every fetched ref, so a value on any pushed branch reaches the scan.

Main is stale-green, not clean. Its last successful scan ran at 2026-08-27T22:35:02Z. The rescue branch was pushed at 2026-08-28T02:25:35Z, about ten minutes later. Main would fail this scan today. Please do not read the green tick on main as evidence the tree is unaffected.

The value is a public key

The manifest key field is the published half of an RSA key pair. Chrome uses it to pin a stable extension ID, so it ships inside every copy of the extension and is public by construction.

Verified independently:

• 392 base64 characters, decoding to 294 bytes
• begins MIIBIjANBgkqhkiG, a SubjectPublicKeyInfo header
• RSA public key, no private material

generic-api-key matched it on the field name key alone. It is the same false-positive shape as openadapt-desktop#138, where the rule matched SIGNING_KEY_SHA256, the digest of FFmpeg's public signing key.

The change

A value-anchored .gitleaks.toml allowlist pinning that one exact literal, following the reviewed desktop pattern.

What it deliberately does not do:

• It does not widen the rule. Any other value in that same field is still reported.
• It does not exempt a path.
• It is not a .gitleaksignore. Those fingerprints are commit-and-line pinned, so they break on the next rebase, which is why the queue-drain doc rejects them.
• It does not delete or rewrite the rescue branch. That branch holds rescued work.

The scan now runs against the reviewed config: gitleaks git . --config .gitleaks.toml.

The durable part is the test

tests/test_gitleaks_allowlist.sh runs in the same job, before the scan. It reads the anchored value back out of the committed config, so it cannot drift from what the scanner actually allows, then:

1. requires the exact published value to be allowlisted,
2. requires that one changed character is still reported, which is the narrowness property,
3. mutates the config by widening the regex to ^[A-Za-z0-9+/=]+$ and requires that this would defeat check 2,
4. mutates the config by adding a path-wide exemption and requires that this would defeat check 2 as well.

Checks 3 and 4 are what stop the allowlist quietly becoming a rule-wide or path-wide exemption later. A scanner left permanently red on a known false positive is how a real leak gets waved through, and an allowlist that silently widens is how one gets waved through quietly.

Validated locally against gitleaks 8.30.1, the exact version the workflow pins. Full-history scan with this config: no leaks found.