chore: retire the last dead paths and names from the consolidation

Nothing here changes what a tool computes; it changes where tools look.

- tools/re-capture: 33 censuses globbed /work/sylph_extract, a path that has
  existed nowhere since /work became a clone, so they matched nothing and
  printed empty results. They now resolve the disc through a new disc.py
  from $SYLPHEED_DISC and exit loudly without it (the #44 fix, generalised).
  Nine scripts that imported siblings from the retired Reborn checkout or an
  old session scratchpad now import from their own directory. unitgroup.py
  only needs the variable when --pak is not given.
- sylpheed-xex: the loader only ever uses the XEX2 retail key. The dead
  devkit key and a doc comment claiming a devkit fallback that does not
  exist are gone; Project Sylpheed is a retail XEX2, so no XEX1 key either.
- sylpheed-viewer: real_font_rasterizes looked for /tmp/sylph_extract and so
  always skipped. It reads $SYLPHEED_DISC now, and passes against the disc.
- Comments and docs that named xenia-rs, the Reborn repository or /work/*.pe
  as places to look now name sylpheed.db, Canary's ppc_context.h and the
  flat .pe; docs/re/README.md no longer says the native Canary build does not
  run.

Historical records keep their original paths: findings that were measured
against /work/xenia-rs/sylpheed.db still say so.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

docs/re/BACKLOG.md

@@ -3579,8 +3579,8 @@ matches build 4. The conclusions are unchanged, the indices are not.
 
 **So the next step is the guest code**, not the file: the splash draw path from
 the emulator-era work (`sub_821CC7A0`, item vtable `0x820b30b4`) submits with
-exactly the PS hash `E59B2B3D` this capture sees, and `xenia-rs/sylpheed.db` is
-available in the container.
+exactly the PS hash `E59B2B3D` this capture sees, and `sylpheed.db` (repository
+root, queried with `tools/zq.py`) is available.
 
 **And a second screen is NO LONGER BLOCKED, but it is not routine either.** The
 main menu has been reached (screenshot in

docs/re/README.md

@@ -101,13 +101,14 @@ XEX load, identical across our emulator and canary.
   `--dump-addr`) went with that emulator when it was retired on 2026-09-16. For static
   `.rdata` reads that `--dump-addr` served, read the `.pe` directly: it is a flat VA dump,
   file offset = `VA − 0x82000000`.
-- **Oracle (correctness ground truth):** canary — the **Wine cross-build**
-  `xenia-canary/build-cross/bin/Windows/Debug/xenia_canary.exe` (the native Linux ELF
-  **crashes / does not run** — do not use it). This is the only emulator that reaches the
-  in-game menu; our retired `xenia-rs` never got past the intro video. Use canary to *observe output*
-  (capture its framebuffer for texture colours), not usually to instrument code — though its
-  `build-cross` toolchain does compile, so small C++ probes + rebuild are possible when needed.
-  Run **muted, one emulator process at a time**, point it at the real ISO (not the symlink).
+- **Oracle (correctness ground truth):** canary, in either of two builds — the **Wine
+  cross-build** in `xenia-canary/build-cross/bin/Windows/Debug/` (launched by
+  `run-canary-safe.sh`) or the **native Linux build** in `xenia-canary-native/` (launched by
+  `run-canary-native-safe.sh`). This is the only emulator that reaches the in-game menu; our
+  retired `xenia-rs` never got past the intro video. Use canary to *observe output*
+  (capture its framebuffer for texture colours), not usually to instrument code — though both
+  builds compile, so small C++ probes + rebuild are possible when needed.
+  Run **muted, one emulator process at a time**, point it at the real ISO.
 
 > ⚠️ **VA-equality caveat:** join **code** by PC (fixed), but **never** assume a data VA
 > holds the same bytes across emulators — allocators differ. Compare data by content/layout.

docs/re/RE_SYMBOLS.md

@@ -115,7 +115,7 @@ extraction limit.
     field registrations (`name → offset`) and default-init stores
     (`offset → value`), join them — heavy, and offset↔name correlation is
     error-prone. (B, runtime) dump a loaded craft object's registry
-    (`obj+64`) / struct from xenia-rs or Canary — a fully-loaded craft already
+    (`obj+64`) / struct from Canary — a fully-loaded craft already
     holds every default; one dump yields `name → value`. **B is the efficient
     finish** given the framework is generic; A's framework map above is the
     prerequisite either way.

docs/re/mission-freeze-resume-spin.md

@@ -172,7 +172,7 @@ in guest memory that never changes.
 The question is now narrow: **which guest PC is the spinning thread executing?**
 Canary knows every `XThread`'s PPC context, so a diagnostic that dumps each
 thread's guest PC on demand (or after N seconds without a frame) would name the
-loop, and `xenia-rs/sylpheed.db` can then say what function it is in. That is a
+loop, and `sylpheed.db` (`tools/zq.py fn <pc>`) can then say what function it is in. That is a
 `build-canary` run plus a reproduction — the cost is worth stating up front, and
 it is the only avenue that does not involve guessing.
 

docs/re/structures/isl-builtins.md

@@ -1251,7 +1251,7 @@ and it is worth recording rather than re-attempting the same way.
 (`%rsi` here, given `mov 0x110(%rsi),%rbx`), so the **guest PC is recoverable
 from the context block** at the moment of the write. Reading the right offset out
 of `$rsi` would name the guest instruction. That needs Xenia's context layout —
-which is in the xenia-rs sources on this box — and is a separate, tractable
+`PPCContext` in Canary's `src/xenia/cpu/ppc/ppc_context.h` — and is a separate, tractable
 piece of work rather than another blind run.
 
 ## 🟡 `sub_8226E458` is a splice — but I have not shown it touches the trigger queue

docs/re/structures/regn-map-grid.md

@@ -379,7 +379,7 @@ nothing rises above chance.
 
 ❔ **What would actually settle it** is the code — find what reads a `REGN`
 object in the executable and watch which fields it dereferences. That is static
-PE work (`/work/*.pe`, offset = VA − 0x82000000) of the same kind that cracked
+PE work (the flat `.pe` in the project root, offset = VA − 0x82000000) of the same kind that cracked
 the `.slb` packing phase, and it is the honest next step rather than a
 twenty-first correlation.
 ---

docs/re/structures/slb-data-offset.md

@@ -322,7 +322,7 @@ self-describing.
 `game:\dat\sound.pak+` and `SETTINGS.PARAM` is `Pj_Silph.xgs`, so there is code
 that opens a bank by name and seeks to its data; the constant, or the table it
 indexes, should be visible there. That is static PE work
-(`/work/*.pe`, offset = VA − 0x82000000), not another pass over the archive —
+(the flat `.pe` in the project root, offset = VA − 0x82000000), not another pass over the archive —
 this page has taken the byte-level evidence about as far as it goes.
 
 

docs/re/ui-title-paint-order-capture.md

@@ -244,7 +244,7 @@ that gets adopted as a rule if only the agreeing five are counted.
 
 ## A foothold in the guest code, and what it is not
 
-The remaining avenue is the code, and `xenia-rs/sylpheed.db` is in the container.
+The remaining avenue is the code, and `sylpheed.db` is in the repository root (`tools/zq.py`).
 What is established so far is small, and stated so it is not mistaken for more:
 
 * **The item class from the splash-era work is real.** Vtable `0x820b30b4` is