fix(review): raise the patch-less secret-scan cap from 512KB to 4MB

[JSONbored]

Summary

Live-diagnosed on the self-hosted ORB box (edge-nl-01) while doing a routine health check across all 3 reviewed repos. metagraphed's secret_leak gate false-positive rate climbed from 38% to 56% over 6 hours per the box's own ops_anomaly self-diagnostic, holding mergeable PRs.

Root cause was not a pattern-match false positive (I initially suspected bittensor_key's hotkey:/coldkey: regex, but safety.ts's secretLeakFinding and content-lane/security-scan.ts both already correctly exclude it from hard-blocking via HARD_SECRET_KINDS). The actual trigger, confirmed from the live PR review comment text, was the fail-closed "content exceeded the scan cap" path in src/queue/patchless-secret-scan.ts:

• metagraphed/public/metagraph/openapi.json: ~1.9MB
• metagraphed/schemas/api-components.schema.json: ~514KB

Both exceed the old 512,000-char SECRET_SCAN_PATCH_FALLBACK_MAX_CHARS cap. Three recent metagraphed PRs (#8106, #8095, #8005 — all regenerating these files as part of an OpenAPI/GraphQL codegen epic) were held for this reason and all merged anyway once manually verified clean (100% false-positive on the recent sample).

Why raising the cap is safe

The underlying fetcher (grounding-wire.ts's makeGithubFileFetcher) already requests the application/vnd.github.raw+json media type specifically to bypass GitHub's Contents API ~1MB base64-JSON envelope ceiling — so the real limit here was always this local constant, not something GitHub imposes. Raising it only expands scan coverage (more content becomes fetchable-and-scannable instead of being marked incomplete-and-blocked); it can't weaken detection on anything the old cap already caught. Fetch count (SECRET_SCAN_PATCH_FALLBACK_MAX_FETCHES=100) and concurrency (SECRET_SCAN_PATCH_FALLBACK_MAX_CONCURRENT=4) stay capped separately, unaffected.

4MB gives real headroom above the largest observed case. Worth noting: loopover's own apps/loopover-ui/public/openapi.json is already 525KB — past the old cap too, so this wasn't metagraphed-specific, just first noticed there because its API surface is largest.

Changes

• SECRET_SCAN_PATCH_FALLBACK_MAX_CHARS: 512_000 → 4_000_000, with an updated doc comment explaining the raw+json bypass and the reasoning above.
• test/unit/patchless-secret-scan.test.ts: replaced 6 hardcoded 512_000/512_001 boundary literals with references to the exported constant, so the tests track the real cap instead of drifting from it (this file's own hardcoded fixtures are exactly what silently broke when I bumped the constant — 5 tests failed until fixed).

Test plan

• npm run typecheck — clean
• test/unit/patchless-secret-scan.test.ts — 54/54 passing
• test/unit/secrets-scan.test.ts — 67/67 passing (adjacent scanner, unaffected)
• GitHub Actions CI (authoritative gate)

[superagent-security]

Superagent didn't find any vulnerabilities or security issues in this PR.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 91.98%. Comparing base (f4f001d) to head (d401de5).
⚠️ Report is 1 commits behind head on main.
✅ All tests successful. No failed tests found.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #8605      +/-   ##
==========================================
- Coverage   92.54%   91.98%   -0.56%     
==========================================
  Files         796      796              
  Lines       79690    79690              
  Branches    24066    24066              
==========================================
- Hits        73749    73304     -445     
- Misses       4803     5311     +508     
+ Partials     1138     1075      -63     

Flag	Coverage Δ
backend	92.94% <100.00%> (-0.79%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
src/queue/patchless-secret-scan.ts	100.00% <100.00%> (ø)

... and 3 files with indirect coverage changes