fix(engine): track-record-summary.js's assertPublicSummaryText still scans evidenceUrls for the same false-positive-crash class #6772 fixed only for the login field

[JSONbored]

Context

Issue #6772 (closed) found that renderTrackRecordSummaryMarkdown throws when a contributor's real GitHub
login happens to contain a PUBLIC_FIELD_BLOCKLIST word (wallet, hotkey, coldkey, reward, payout,
ranking, etc.) bounded by a hyphen — e.g. my-wallet, coldkey-labs — because the blocklist regexes use a
bare \b word boundary, and a hyphen is a non-word character in JS regex, so /\bwallet\b/iu matches inside
team-wallet just as readily as inside the bare word wallet. The fix (present in the current code,
track-record-summary.ts:442-446) excludes the GitHub login: line from the scanned text, with the comment:
"Scanning the whole block including the identity line was the bug."

Two things are still wrong:

1. The identical false-positive-crash mechanism still applies to evidenceUrls. bodyLines (line
   437-439) includes summary.incidents.evidenceUrls.map((url) => markdownSafe(url)).join(", "), and
   bodyLines (the full array, including this line) is exactly what assertPublicSummaryText scans (line
   446). evidenceUrls are real GitHub/public URLs pointing at incident evidence (issues, PRs, comments) —
   their repo name or path segments are just as capable of legitimately containing a hyphen-bounded
   blocklisted word as a login is (https://github.com/some-org/wallet-connect/issues/12,
   .../crypto-payout-service/pull/9, .../trust-score-dashboard/...). markdownSafe only escapes markdown
   syntax characters, not word content, so nothing currently prevents this. A repo genuinely named
   wallet-*/hotkey-*/reward-*/etc. would make ANY contributor's public track-record summary that cites
   evidence there throw, exactly the class of bug Track-record summary throws on a legitimate GitHub login that collides with the safety blocklist #6772 fixed for login but left open here.

2. Track-record summary throws on a legitimate GitHub login that collides with the safety blocklist #6772's own required regression test was never added. Track-record summary throws on a legitimate GitHub login that collides with the safety blocklist #6772's Deliverables explicitly required:
   "Regression test with login: \"team-wallet\" (or similar) asserting successful rendering instead of a
   throw." packages/loopover-engine/test/track-record-summary.test.ts has no such test today (confirmed:
   no occurrence of team-wallet, and no test constructs any login value containing a blocklisted
   substring at all) — meaning the shipped fix for the ORIGINAL bug is itself currently unverified by any
   test, on top of the still-open gap in item 1.

Requirements

• Fix the same class of false positive for evidenceUrls (and any other computed field folded into
  bodyLines that can legitimately carry caller/GitHub-sourced free text) the same way Track-record summary throws on a legitimate GitHub login that collides with the safety blocklist #6772 fixed it for
  login: either exclude URLs from the blocklist scan (URLs are structural GitHub links, not a leakable
  computed signal — the same rationale Track-record summary throws on a legitimate GitHub login that collides with the safety blocklist #6772 used for login), or scan them with a narrower check that
  doesn't false-positive on a hyphen/slash-bounded substring.
• Add the regression test Track-record summary throws on a legitimate GitHub login that collides with the safety blocklist #6772 already required but never got: a login containing a blocklisted
  substring (e.g. "team-wallet") renders successfully.
• Add the new regression test this issue requires: an evidenceUrl whose path contains a blocklisted
  substring (e.g. https://example.test/org/wallet-connect/issues/1) renders successfully.
• Preserve the existing fail-closed behavior for a genuinely-injected blocked term in a COMPUTED field (the
  existing test at line 604, renderTrackRecordSummaryMarkdown fails closed if a blocked public field is introduced, must continue to pass unchanged).

Deliverables

• evidenceUrls (and any other caller/GitHub-sourced identity-like field folded into bodyLines)
  excluded from, or safely re-scanned against, the public-safety blocklist the same way login already
  is.
• Regression test: login: "team-wallet" renders successfully (the test Track-record summary throws on a legitimate GitHub login that collides with the safety blocklist #6772 required and never got).
• Regression test: an evidenceUrl containing a blocklisted substring (hyphen- or slash-bounded) renders
  successfully instead of throwing.
• The existing fail-closed regression test (line 604) still passes.

Test Coverage Requirements

99%+ Codecov patch coverage (branch-counted) on every changed line. Both new regression tests above are the
actual proof this issue is fixed — without them, this exact class of false-positive crash has now shipped
unverified twice in a row.

Expected Outcome

A contributor's real GitHub login, AND any legitimate public evidence URL cited in their track-record
summary, can contain a blocklisted word as a hyphen/slash-bounded substring without crashing
renderTrackRecordSummaryMarkdown — while a genuinely-injected blocked term in a computed field still fails
closed exactly as before.

Links & Resources

• packages/loopover-engine/src/track-record-summary.ts (PUBLIC_FIELD_BLOCKLIST lines 115-126,
  assertPublicSummaryText lines 236-242, renderTrackRecordSummaryMarkdown lines 424-452)
• packages/loopover-engine/test/track-record-summary.test.ts (existing fail-closed test at line ~604)
• Track-record summary throws on a legitimate GitHub login that collides with the safety blocklist #6772 (closed) — the original login false-positive fix and its own (unmet) test-deliverable

[linear-code]

JSO-5305