docs: anchor the checklist citations to headings and symbols, not line numbers

Line numbers rot silently. Ten were already broken, including all eight Precision invariants pointers. Vendor citations left alone.

docs/TODO.md

@@ -247,9 +247,9 @@ dynamically... Toggling the limiter killing the voices isn't a deal breaker thou
 will either be on or off on its instance, toggling during playback is not a use case."*
 
 **The wart — and it is ours, not the SDK's.** `ReaSamplerProcessor::setActive(true)` calls
-`reloadInstrument()` (`src/shell/instrument/reasampler_processor.cpp:89-97`) — a bridge read
+`reloadInstrument()` (`reasampler_processor.cpp`'s `ReaSamplerProcessor::setActive`) — a bridge read
 plus a **full WAV re-decode** plus a fresh engine. `setActive(false)` frees `live_`,
-`draining_` and the graveyard (`:98-107`). So every host-driven activation cycle — a
+`draining_` and the graveyard (`ReaSamplerProcessor::setActive`). So every host-driven activation cycle — a
 latency-change restart, an offline-render bracket, any host that deactivates around transport
 state — pays a disk read and a decode that nothing about activation requires. **Activation
 currently means two things at once**: "the audio thread may run" and "the decoded `SampleData`
@@ -269,7 +269,7 @@ die across the cycle** — only the decoded PCM survives, and those are two diff
 currently collapsed into one. Second constraint: `setActive(true)` is also the non-editor
 legacy-lift trigger for a pre-v10 blob (its opportunistic `refreshRefsFromBank` copies refs in
 once the bank blob is readable), so a path that skips the bridge read must keep that lift
-reachable — the comment at `:90-96` records the residual load-order race it exists to cover.
+reachable — the comment in `ReaSamplerProcessor::setActive` records the residual load-order race it exists to cover.
 
 **Priority / risk.** Low; deferred by ruling. Nothing is incorrect today, only wasteful, and
 Daniel has explicitly accepted the user-visible consequence (held notes cut on a limiter
@@ -530,7 +530,7 @@ needs no live REAPER process to exercise `rec->Register(...)` calls. Once
 **The constraint the fix MUST handle.** The extraction alone buys nothing:
 `action_registry` has no test target today either, so lifting `ingestHandleSectionCommand`
 into it without also standing up the test target just relocates the untested code. The
-same follow-up could collapse `ingest.cpp:466-472`'s hand-rolled `command_id`+`gaccel`
+same follow-up could collapse `ingest.cpp`'s `ingestRegisterActions` hand-rolled `command_id`+`gaccel`
 pair onto `action_registry::registerAction`, which already does exactly that dance for
 the Q-W6 table.
 
@@ -565,7 +565,7 @@ track", nothing to do and the inference is retired into fact. If it comes back "
 summed file", the refusal is over-strict for the TRACK scope and should be narrowed back
 — and the ITEM-scope half is then an OPEN question, not settled: a full-extent item
 capture already sums a multi-track item selection via `&32|single-file`
-(`tests/test_render_settings.cpp:262`), so if `&128` also sums, a ranged item capture
+(`test_render_settings.cpp`'s `testMultiTrackStemRenderIsNamedForRefusal`), so if `&128` also sums, a ranged item capture
 routed through it sums too, and keeping the item refusal in that branch would make item
 scope inconsistent with itself across the range boundary (full-extent sums, ranged
 refuses, same scope). Whether that inconsistency is acceptable or the item refusal should
@@ -798,8 +798,8 @@ the two callers' plumbing.
 
 **Context.** `saveToActiveProject()` returns false for exactly two reasons — no active
 project, or an unsaved one — and in both cases NOTHING was written. Four capture sites
-discard that return outright: `capture_orchestrator.cpp:343`, `capture_batch.cpp:266` and
-`:333`, and `realtime_lifecycle.cpp:39`.
+discard that return outright: `capture_orchestrator.cpp`'s `RunCapture`, `capture_batch.cpp`'s
+`RunBatchCaptureItems` and `RunBatchCaptureRazor`, and `realtime_lifecycle.cpp`'s `CommitRealtimeResult`.
 
 **The wart.** A capture on an unsaved project renders the file into the bank folder, adds
 the `Sample` to the in-memory book, records a birth record in memory — and loses all three
@@ -820,7 +820,7 @@ and the choice between those two is recorded rather than implicit.
 
 ## `panel_input`'s wheel handler persists the whole book per wheel message
 
-**Context.** `panel_input.cpp:450` — `handleWheel` calls `markTailDirty()` on every wheel
+**Context.** `panel_input.cpp` — `handleWheel` calls `markTailDirty()` on every wheel
 message that actually moves `manualMs`, while the pointer is over the footer in Manual
 mode. (It coalesces sub-notch deltas within ONE message and no-ops at a bound, so the
 count is wheel messages that changed the value, not raw notches.)
@@ -839,10 +839,10 @@ the value that lands is the gesture's final one.
 
 ## `RunCaptureItemAssign`'s undo point does not follow the pattern its comment claims
 
-**Context.** `capture_orchestrator.cpp:364-365` states that the action follows the bank-op
-family's discard-on-unsaved pattern.
+**Context.** `capture_orchestrator.cpp`'s `RunCaptureItemAssign` states that the action follows
+the bank-op family's discard-on-unsaved pattern.
 
-**The wart.** It does not: `:382-383` records the undo point unconditionally whenever
+**The wart.** It does not: `RunCaptureItemAssign` records the undo point unconditionally whenever
 `sampleId` is non-empty, and never consults the persist's return at all. So on an unsaved
 project it records an undo point for ext-state that was never written — the empty
 no-effect entry `persistBankOp`'s guardrail exists to avoid. The comment describes the
@@ -857,7 +857,8 @@ the unsaved-project case one way.
 
 ## `core/tracking/CLAUDE.md`'s untracked-file enumeration says "reaches the `.rpp`" too loosely
 
-**Context.** `src/core/tracking/CLAUDE.md:24-31` enumerates how a created file can stay
+**Context.** `src/core/tracking/CLAUDE.md` §"Invariants" — "No silent gaps — in memory at
+creation, on disk at the next save" — enumerates how a created file can stay
 untracked, and describes the ledger as reaching the `.rpp` at the following
 `saveToActiveProject()`.