ops: detect malformed TODO issue references in todo-checker

[claude]

Requested by Adrian Sutton · Slack thread

Before: todo-checker.sh only saw comments already written in the TODO(<ref>) form. A TODO that clearly referenced an issue but was slightly malformed — e.g. TODO:(#123), TODO (#123), TODO[#123], TODO: #123, or FIXME equivalents — was silently ignored, so it never got format-checked or swept when the issue closed. The tree has exactly one such comment: TODO:(#18382) in OPContractsManagerV2.sol:364 (stray colon before the paren), invisible to the checker since it was added.

After: the checker flags malformed issue references as errors under --strict (the mode every main CI pipeline runs), with a warning pointing at the exact line and the expected TODO(<ref>): <description> format. Additionally, a valid TODO(<ref>) with no trailing description (e.g. TODO(client-pod#826)) — previously also invisible because the capture regex required trailing text — is now tracked by the existing format and closed-issue checks.

Note on the one existing offender: the OPContractsManagerV2.sol:364 fix is deliberately NOT included here — issue #18382 is closed, so fixing the format in this PR would make the scheduled --check-closed job fail. That comment gets fixed (or removed) in a separate PR, and this PR's strict todo-issues check will stay red until that lands — expected, and why this PR stays draft/unmerged for now.

Also in this PR: the script now fails fast with an [Error] when ripgrep is not installed — previously a missing rg made every scan come back empty and the script exited 0 having checked nothing.

How: a new near-miss scan runs after the main check: it greps for a TODO/FIXME token followed within a few punctuation/whitespace characters by an issue-reference-looking token (#123, repo#123, or org/repo#123), then subtracts lines already using the parenthesized TODO(...)/FIXME(...) form (those are the main check's domain). The short window is the false-positive guard: prose like TODO: fix the bug from PR #123 or a bare TODO: fix this later is not flagged, and neither are hex colors or markdown headings, because letters can't appear between the token and the reference. Same exclusion globs as the main scan; near-misses warn in --verbose and fail the run in --strict, exactly like format mismatches. Verified: the scan flags the :364 near-miss and nothing else across the whole tree, and the existing 63 canonical matches are unchanged by the regex relaxation (the only additions are the two previously-invisible valid-ref lines).