doctor: check results cite private-tracker issue numbers, one of which links to an unrelated public issue #205

palinode doctor attaches a linked_issue to some check results, and --format json prints it (palinode/diagnostics/formatters.py:59). Three values ship from the diagnostics package, and all three are issue numbers from the private development tracker rather than this repository's:

#190 is the worst of the three because it does not look broken. Someone debugging a missing memory directory follows the link and lands on a rounding-rule issue, with no signal the reference was never meant for this repository.

#371 is the one to be careful with. Line 36 is _LINKED_ISSUE = "#371", a module constant referenced by six CheckResult branches — so a search for linked_issue="# will not find it. Line 122 is a bare #371 inside a remediation message, which the user reads directly. Fix both.

A guard for this rule already exists, and it has a hole. tests/test_no_issue_refs_user_surface.py enforces the no-bare-reference rule across CLI help, MCP schema descriptions, Python comments, docstrings, CI workflow comments, and root config files. It does not scan string literals, which is where all ten of these live. Its docstring explains the rule and the escape hatch: a bare #NNN is unfollowable; a full public URL is fine.

What the PR should do:

1. Fix all ten references. For each, either cite the full public URL if a public issue genuinely covers it, or remove the reference and let the message stand on its own. linked_issue is str | None (types.py:24) and None is already the default for most checks, so removal is valid and usually right. Do not invent a mapping to keep the field populated. In recall_write_health.py, that means the constant and the mention inside the remediation text.

2. Add a guard scoped to this package. A new test asserting that no string constant in palinode/diagnostics/ carries a bare issue reference — constants included, which is what makes it catch the _LINKED_ISSUE shape. The existing file already walks source with tokenize (_comment_refs_in, line 151); an ast pass over string constants is the simpler route here, and either is fine.

Scope it to palinode/diagnostics/ and say so in the test's docstring. Do not widen it to the whole repository: there are further bare references elsewhere in palinode/ whose correctness has not been assessed, and — more importantly — intentional fixtures would fail, including this guard's own test_bare_number_is_rejected (line 304), which contains "Issue #100: the body was mangled." on purpose. A repository-wide policy is a separate decision and not part of this issue.

Verify it bites: put a bare #1234 into one of the fixed values, confirm your new test fails, then remove it. A guard nobody has watched fail is a guard nobody knows works — which is how ten references survived a rule written to forbid them.

Scope: the three check modules and tests/test_no_issue_refs_user_surface.py. No behaviour change to any check — only reference strings and the new test.

Context, not scope: the same class was fixed in the parity registry in #204 last week; that thread has the reasoning.

Comment here to claim it. Please wait to be assigned before opening a PR — two contributors landed on one issue once because we had no such line.