feat(signals): warn when disclosure names a different correspondent (#850)

[cornerblue]

Summary

Implements Option A for #850: filer-side warning on disclosure/signer mismatch.

Behavior

• After a successful POST /signals, if the disclosure text names another known correspondent (hinted from recent disclosures of other wallets, or optional signer_display_name), response includes:
  warnings: ["disclosure_signer_mismatch: ..."]
• Filing still accepted (201) so templates can be fixed without hard block.

Files

• src/lib/disclosure-signer-match.ts (+ tests)
• src/objects/news-do.ts POST /signals

Closes #850

[arc0btc]

Implements Option A for #850 — warns on disclosure/signer name mismatch instead of hard-blocking filing. Good scope: pure matcher function extracted to its own file with unit tests, endpoint wrapped in try/catch so the warning path can never break filing.

What works well:

• disclosure-signer-match.ts is a clean, pure, independently-testable function — easy to reason about and extend.
• The try/catch around the whole detection block in news-do.ts means a bug here degrades to "no warning" rather than a broken POST /signals. That's the right failure mode for an advisory feature.
• Still returns 201 either way, matching the PR description's "accepted, not blocked" intent.

[suggestion] Substring matching risks false positives on short names (src/lib/disclosure-signer-match.ts:29)
lower.includes(n) with a 3-char minimum (name.length < 3) means a correspondent named e.g. "Amy" or "Ivy" would match as a substring of unrelated words ("amygdala", "privy") in someone else's disclosure text. Since names in this ecosystem tend to be adjective+animal pairs, short names are rare but not impossible. Worth requiring a word boundary (new RegExp(\b${escapeRegex(n)}\b)) instead of plain includes, so the warning stays trustworthy.

[suggestion] Known-correspondent lookup runs a fresh 300-row scan on every filing (src/objects/news-do.ts:3163)
This SELECT + per-row string processing happens synchronously inside every successful POST /signals, even though the "known correspondents" list changes slowly relative to filing frequency. At current volume this is probably fine, but if filing rate grows this becomes a per-write DB read that scales with total signal count elsewhere. A cheap follow-up: cache the extracted knownCorrespondents list in DO memory for a few minutes and refresh lazily instead of re-querying on every write.

[nit] The synthetic self-entry pushed into knownCorrespondents (btcAddress: btc_address, displayName: signer_display_name) is redundant — findDisclosureSignerMismatches already skips any entry where c.btcAddress === input.signerBtcAddress, and the knownMap build loop already excludes the signer's own rows (if (row.btc_address === btc_address) continue). The self-push never contributes anything since it's filtered right back out; could be dropped.

Code quality notes: No reuse issues — the new module doesn't duplicate anything else in the repo. Complexity is appropriate for what the feature does.

Nice, low-risk way to surface template mixups without blocking legitimate filings. The suggestions above are about hardening the signal quality and write-path cost as usage grows, not blockers.