Fix bare-word hotkey/coldkey false positives in containsSecretLikeText + static-message redaction bug

[JSONbored]

Implements #7980.

Problem

containsSecretLikeText (src/review/content-lane/registry-logic.ts:101) matches the bare words hotkey/coldkey anywhere in a JSON-stringified subnet/provider document, with no adjacency/context requirement — unlike wallet, which is correctly scoped to the phrase "wallet path". In the Bittensor/Gittensor domain "hotkey" is the standard public miner identifier, not secret material, and appears routinely in legitimate registry content (API paths like /miners/hotkey/{hotkey}, field names like miner_hotkey, even explicit denials like "No wallet/hotkey data"). Confirmed root cause of 4 mis-closed metagraphed PRs in one day (#7469, #7589, #7591, #7594 — filed against JSONbored/metagraphed), 3 of which remain incorrectly closed. Because assessSubnetDocument scans the WHOLE file (not just the diff), any future PR touching an already-affected file is permanently blocked until this ships.

Separately: the blocker text rendered to contributors/maintainers reads "...secret, [context], PAT..." instead of "...secret, wallet, PAT..." — PRIVATE_FORBIDDEN_TERMS's scrub (src/review/unified-comment-bridge.ts:80, mirrored in src/rules/advisory.ts's CHECK_RUN_FORBIDDEN_TERMS) is being applied to a static, hardcoded, non-dynamic message template, not just AI-generated text, degrading the bot's own explanation of what it found.

Area

src/review/content-lane/registry-logic.ts (secret scanner); src/review/unified-comment-bridge.ts + src/rules/advisory.ts (public-text redaction).

Proposal

• Scope hotkey/coldkey the same way wallet already is: require adjacency to something indicating actual key material (e.g. a real SS58/base58-shaped value, or a "private"/"seed" qualifier) rather than a bare word match. Add regression tests using the exact 4 incident payloads (or equivalent minimal repros) as fixtures, asserting they now pass.
• Exempt the reviewer's own static, engineer-authored message templates from PRIVATE_FORBIDDEN_TERMS/CHECK_RUN_FORBIDDEN_TERMS scrubbing — that scrub exists to catch a private rubric term LEAKING into AI-generated or dynamically-assembled text, not to sanitize a hardcoded string an engineer already reviewed. Add a regression test asserting "wallet, PAT, or private-key material" renders verbatim.
• Manually re-review and, if appropriate, reopen/merge fix(review): paginate preview-url.ts's PR-comment and check-run GitHub reads #7469, Epic: dual-path repo provisioning — BYOR + APR #7589, Design spec: idea-completion determination + customer-facing status for APR (no GitHub UI exposure) #7591 once the fix ships (a maintainer action once deployed, not part of this PR).

Deliverables

• Passing fix + tests in registry-logic.ts and the redaction path.
• A short note on which repos/files were affected repo-wide (any other subnet file matching the old pattern), so a targeted sweep can confirm no other files are silently blocked.

Resources

• metagraphed fix(review): paginate preview-url.ts's PR-comment and check-run GitHub reads #7469, Epic: dual-path repo provisioning — BYOR + APR #7589, Design spec: idea-completion determination + customer-facing status for APR (no GitHub UI exposure) #7591, fix(ui): give four app-panel form controls a programmatic accessible name #7594 (evidence)
• test/unit/ (existing content-lane test suite to extend)

Boundaries

Scoped to this exact regex bug and the redaction bug. Does not touch the broader self-correction architecture (sub-issues 2-6 of #7980).

maintainer-only — security/content-lane logic, not contributor-scoped.

[linear-code]

JSO-5511