docs: anchor the product-doc citations to symbols, not line numbers

Ten more were already pointing at unrelated code. Vendor SDK and SWELL citations left alone — those files don't move.

docs/product/code-organization.md

@@ -226,25 +226,25 @@ them through the reorg, not to change them:
 These are the naming equivalent of the JSON-`Parser` DRY violation — concrete hazards, not taste:
 
 1. **Four hand-rolled `Parser` classes, one name.** `class Parser` is defined **four times** —
-   `bank_model.cpp:306`, `bank_book.cpp:663`, `owned_manifest.cpp:107`, `view_mode_model.cpp:654`.
+   `bank_model.cpp`, `bank_book.cpp`, `owned_manifest.cpp`, `view_mode_model.cpp`.
    Q-W1 already deletes three of them by extracting `core/json`; the naming rule is that the
    survivor is **`json::Parser`** (or a more specific `json::Reader`/`json::Writer` pair — see
    Q-8), never a bare `Parser` in flat scope.
 2. **`FooterRect` and `ButtonRect` are shared across pure UI modules — and the codebase already
    *knows* it.** `struct FooterRect` and `struct ButtonRect` are defined in `prune_button.h`
-   (lines 32, 46) and **reused** by `footer_bar.h`, which carries an explicit in-file "NAME NOTE"
-   (`footer_bar.h:27–34`) documenting that `ButtonRect / FooterRect / SegmentRect / ActionBarRect /
+   and **reused** by `footer_bar.h`, which carries an explicit in-file "NAME NOTE"
+   (`footer_bar.h`) documenting that `ButtonRect / FooterRect / SegmentRect / ActionBarRect /
    KitBox / KitButtonBox` are "already owned in this namespace" and that new types must carry a
    `FooterBar*` prefix to avoid collision. That comment is a smell made visible: the flat
    `reasampler::` namespace forces every pure-UI author to hand-check for name collisions before
    minting a type. This is the single strongest in-codebase argument for the Q-4 sub-namespaces —
    under `reasampler::ui` these shared rect types get one clear owner and the hand-checking stops.
-3. **`Sample` (`bank_model.h:69`, the bank metadata struct) vs `AudioSample` (the `peaks` float
+3. **`Sample` (`bank_model.h`'s `Sample` struct, the bank metadata struct) vs `AudioSample` (the `peaks` float
    alias).** Already flagged in §2.4/Q-4; verified — `Sample` is the model record, `AudioSample`
    is a raw PCM float. Under `model::Sample` vs `audio::AudioSample` the collision risk is gone,
    but the *names* still read oddly side by side (a `Sample` that is metadata, an `AudioSample`
    that is one float). Noted; the namespace split is the required fix, a rename is optional (Q-8).
-4. **`Selection` (`bank_grid.h:112`) and `CellRect` (`bank_grid.h:23`) are generic names in a
+4. **`Selection` (`bank_grid.h`'s `Selection` struct) and `CellRect` (`bank_grid.h`'s `CellRect`) are generic names in a
    flat namespace.** `Selection` in particular is the kind of name a newcomer cannot place without
    opening the file. `ui::Selection` / `ui::CellRect` resolve it structurally; no rename needed
    beyond the namespace.
@@ -255,23 +255,23 @@ Here the names are legal and non-colliding but do not read on one principle —
 at" gap:
 
 1. **The model-family suffixes disagree: `_model` vs `_book` vs `Index`.** Verified: the pure model
-   modules are `bank_model.{h,cpp}` (owning `class BankIndex`, `bank_model.h:132`), `bank_book.{h,cpp}`
-   (owning `class BankBook`, `bank_book.h:208`), `view_mode_model.{h,cpp}` (owning `class ViewModeModel`,
-   `view_mode_model.h:376`), `owned_manifest.{h,cpp}` (owning `class OwnedFileManifest`,
-   `owned_manifest.h:52`). Four modules, four different file↔class naming relationships:
+   modules are `bank_model.{h,cpp}` (owning `class BankIndex`, `bank_model.h`), `bank_book.{h,cpp}`
+   (owning `class BankBook`, `bank_book.h`'s `BankBook`), `view_mode_model.{h,cpp}` (owning `class ViewModeModel`,
+   `view_mode_model.h`'s `ViewModeModel`), `owned_manifest.{h,cpp}` (owning `class OwnedFileManifest`,
+   `owned_manifest.h`). Four modules, four different file↔class naming relationships:
    `bank_model`→`BankIndex` (file says "model," class says "index"), `bank_book`→`BankBook`
    (file = class), `view_mode_model`→`ViewModeModel` (file = class), `owned_manifest`→`OwnedFileManifest`
    (file ≈ class, but the class adds "File"). The `bank_model`/`BankIndex` mismatch is the worst:
    the file name and its primary class name share no word. This is a genuine legibility wart — the
    fix is a *rename decision* (Q-8), not something the directory move alone resolves.
 2. **The `bank_book` "wraps `bank_model`" relationship is invisible in the names.** `BankBook`
-   (`bank_book.h:208`) is a registry of `Bank` (`bank_book.h:147`), each wrapping a `BankIndex`
-   (`bank_model.h:132`). The names `Book` → `Bank` → `Index` do not read as a containment hierarchy;
+   (`bank_book.h`'s `BankBook`) is a registry of `Bank` (`bank_book.h`'s `Bank` struct), each wrapping a `BankIndex`
+   (`bank_model.h`). The names `Book` → `Bank` → `Index` do not read as a containment hierarchy;
    a reader has to learn it. (Not necessarily worth a rename — "book of banks" is evocative — but
    it is the kind of call Q-8 should make deliberately, not by accident.)
 3. **`realtime_record.h` (pure) vs `capture_realtime.cpp` (shell) — the word order flips.** Verified:
    the pure realtime module is `realtime_record.{h}` (owning `RecordModePlan`/`RecordPhase`/
-   `RecordTickInputs`, `realtime_record.h:57–173`) while its shell is `capture_realtime.cpp`. So the
+   `RecordTickInputs`, `core/capture/capture_realtime.h`) while its shell is `capture_realtime.cpp`. So the
    pure core is `realtime_record` but the shell is `capture_realtime` — the two halves of one feature
    are named on inverted word order (`realtime_record` vs `capture_realtime`). Compare the *clean*
    shell-pair convention elsewhere: `drag_out` (pure) ↔ `drag_out_win` (shell) — same stem, suffix
@@ -279,7 +279,7 @@ at" gap:
    naming-drift instance in the tree (Q-9).
 4. **`capture.{h,cpp}` is the *offline* backend shell, but the name claims all of capture.**
    Verified: `capture.h` declares `ICaptureBackend`, `OfflineRenderBackend`, **and**
-   `RealtimeRecordBackend` (`capture.h:112,124,201`), while the realtime *implementation* lives in
+   `RealtimeRecordBackend` (`capture.h`'s `OfflineRenderBackend`), while the realtime *implementation* lives in
    `capture_realtime.cpp` and its pure planner in `realtime_record.h`. So `capture` is really
    "capture interface + offline backend," a fat header (the §2.3 Interface-Segregation concern) whose
    name oversells its scope. Its Q-W3 hoist (`capture_orchestrator`/`scope_resolve`) is the moment
@@ -290,11 +290,11 @@ at" gap:
 Swept for names a newcomer couldn't decode; the tree is mostly clean here (a credit to it). Two
 minor notes:
 
-- **`guid_diff` / `GuidBaseline` (`guid_diff.h:40`)** — "GUID diff" is decodable in context (it
+- **`guid_diff` / `GuidBaseline` (`guid_diff.h`'s `GuidBaseline`)** — "GUID diff" is decodable in context (it
   diffs the live track/item GUID set between polls) but `GuidBaseline` reads more clearly as "the
   previous-poll snapshot" than the module name suggests. Low priority; leave unless its `core/view`
   relocation invites it.
-- **`MinMax` (`peaks.h:30`), `KitBox` (`component_geometry.h:28`)** — terse but correct and local;
+- **`MinMax` (`peaks.h`'s `MinMax`), `KitBox` (`component_geometry.h`'s `KitBox`)** — terse but correct and local;
   no change. Named here only to record they were swept and cleared.
 
 ### 2b.5 What the naming audit does NOT touch (hard boundary)