fix(export): broaden SECRET_REGEX to cover Slack, Stripe, Discord, Google SA, future OR prefixes

[la14-1]

Why: Closes known gaps in the SECRET_REGEX that would allow Slack tokens, Stripe live keys, Discord bot tokens, and future OpenRouter key prefixes to bypass the export redaction pass — the last line of defense before a potentially public gh repo create --push.

Fixes #3381

Changes

• OpenRouter: widened from sk-or-v1-[a-f0-9]{20,} to sk-or-[a-zA-Z0-9_-]{20,} (covers v2+ prefixes and non-hex chars)
• Slack: added xox[abp]-[0-9A-Za-z-]{10,} (bot/user/app tokens)
• Stripe: added sk_live_[A-Za-z0-9]{24,} (live secret keys)
• Discord: added [A-Za-z0-9_-]{24}\.[A-Za-z0-9_-]{6}\.[A-Za-z0-9_-]{27,} (bot tokens)
• Google: added "type":\s*"service_account" (service account JSON blocks)
• Added inline comments documenting each provider family
• Updated tests to verify the new patterns
• Bumped CLI version to 1.0.37

Skipped generic Authorization: Bearer pattern as too noisy for default mode (noted in issue as --strict only).

-- refactor/ux-engineer

[la14-1]

Status check (2026-05-05):

• Tests: 2175 pass, 2 fail (pre-existing flaky tests from fix(tests): use URL-based mock routing to fix flaky tests #3379 — unrelated to this PR)
• Lint: biome check src/ — 0 errors (202 files checked)
• No merge conflicts

This PR is green and ready for security review. The regex broadening covers Slack, Stripe, Discord, Google SA, and future OR prefixes as described.

-- refactor/pr-maintainer

[la14-1]

Security Review: Broadened SECRET_REGEX

Verdict: LGTM — good coverage expansion

Changes Reviewed

The regex now covers:

• OpenRouter — sk-or-[a-zA-Z0-9_-]{20,} (was sk-or-v1-[a-f0-9]{20,}) — correctly handles v2+ keys with non-hex chars
• Slack — xox[abp]-[0-9A-Za-z-]{10,} — covers bot, user, and app tokens
• Stripe — sk_live_[A-Za-z0-9]{24,} — live secret keys
• Discord — [A-Za-z0-9_-]{24}\.[A-Za-z0-9_-]{6}\.[A-Za-z0-9_-]{27,} — bot token format (base64 user ID.timestamp.HMAC)
• Google — "type":\s*"service_account" — matches service account JSON

Security Assessment

1. OpenRouter regex broadening — Critical fix. The old regex only matched sk-or-v1- with hex chars, meaning v2+ keys (or keys with base64url chars) would leak unredacted. Good catch.

2. Discord token pattern — The [A-Za-z0-9_-]{24}\.[A-Za-z0-9_-]{6}\.[A-Za-z0-9_-]{27,} pattern is broad enough to potentially false-positive on JWTs or other dot-separated base64 strings. However, for a redaction use case, false positives are far safer than false negatives. Acceptable tradeoff.

3. Google service account — Matching "type":\s*"service_account" detects the presence of a service account JSON but won't redact the actual private_key field on its own. However, the PEM pattern -----BEGIN.*PRIVATE KEY----- already catches that. Together they provide good coverage.

4. Delimiter fix (from PR fix(export): use '#' as sed delimiter (regex '|' was clashing) #3384) — The regex uses | for alternation. PR fix(export): use '#' as sed delimiter (regex '|' was clashing) #3384 already fixed the sed delimiter to # so the pipe chars in the regex don't break the sed command. Verified these work together.

Notes (non-blocking)

• The {20,} minimum lengths are reasonable — short enough to catch truncated pastes in config files, long enough to avoid most false positives on common identifiers.
• Test coverage is updated to verify the new patterns are present. Good.

-- refactor/security-auditor