Retire docs/findings/, migrating the record to GitHub issues

[Yaraslaut]

Retires docs/findings/ and moves the finding record to GitHub issues.

Capture before deletion

Three of the six were already captured by closed issues, so removing the file loses nothing:

Finding	Record
r5-001	#130, closed
r5-002	#131, closed
r5-003	#129, closed

The other three had no durable record anywhere — two had no linked issue at all — so they were migrated first, with their full text:

Finding	Migrated to	Note
r4-001	#343	severity major; no issue existed
r4-002	#344	no issue existed
r5-004	#345	upstream Lightweight#583 is still open — this was a live finding, not a settled one

This follows cf68403f's rule for removing a finding: content durably captured elsewhere first, "never leaving a bare historical record behind."

examples/FINDINGS.md

Now describes an issue-based pipeline. Dispositions become triage: labels and the issue's own state carries whether the finding is open; triage, fix budget, exit criteria and demotion policy are unchanged.

The id-allocation machinery was entirely about file naming and retires with the directory — but two pieces of its reasoning are kept, because they are why that scheme existed and why it stopped:

• a global sequence does not survive parallel branches, and did not — "a rule that every violation already satisfies is not a control";
• a stale citation must look stale rather than resolve silently to the wrong file. That hazard survives the move, which is not hypothetical: finding 004 citations in the tree resolve today to the renamed r5-004, an unrelated finding (see Ten code comments cite findings by bare id, which the new findings-citation lint cannot see #340).

The lint check

check_spec_citations.sh's findings-citation check is removed rather than retuned. It required at least three findings-path citations as a vacuity guard; with the directory gone that floor can never be met, so it would fail every run for a reason unrelated to drift. Lowering the floor to zero would restore exactly the vacuous pass the floor existed to prevent.

One subtlety worth review. The self-test blinds scans by position. The findings scan was the second git ls-files invocation matching that pattern, so break_section_scan's index moves 3 → 2. Left unchanged it would have blinded the wrong scan and waited for a diagnostic that no longer exists — a self-test that silently stops testing. The "the section-citation scan's own file glob going stale" case still passing is what pins this.

The residual half of the class — comments citing a finding by bare id with no path, which a path scan never saw — is tracked in #340.

Citations

Repointed at the capturing issue (docs/GETTING-STARTED.md, examples/kanban/README.md) or reworded to describe the gap directly (examples/pastebin/README.md, examples/bookmarks/README.md, and examples/common/wasm_spike/README.md, whose instructions for allocating a new id no longer had a directory to allocate in).

docs/superpowers/ is deliberately untouched — dated records of what was planned, which the lint excludes by design.

Verification

scripts/check_spec_citations.sh and scripts/test_check_spec_citations.sh both pass; all 9 remaining self-test cases green.

Open question for the reviewer

examples/FINDINGS.md's back-fill section still says back-filling review-round findings is "the first task of rung 0". That reads oddly now that the mechanism has changed under it, but rewriting the program's stated sequencing felt beyond a retirement PR. Flagging rather than deciding.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!