docs: stop telling people to use the retired xenia-rs

Instructions and generated text that still sent readers to `xenia-rs`, which is
archived and deleted locally. Provenance and dated research records are left as
they are — "lifted from xenia-rs", or a finding stating what database it was
measured against, is still true, and rewriting it would falsify the record.

Changed, because each one tells someone what to do today or writes stale text:

  docs/re/README.md          the RE toolchain guide queried `xenia-rs/sylpheed.db`
                             with `xenia-rs/zq.py`, and its "Dynamic" bullet said
                             to prefer xenia-rs's probe suite OVER Canary. Now:
                             `sylpheed.db` at the repo root (how to build it and
                             re-stamp names), `tools/zq.py`, dynamic = Canary, and
                             `.rdata` reads from the `.pe` (offset = VA - 0x82000000)
                             in place of `--dump-addr`.
  challenge-mission-gate.md, structures/achievements.md
                             reproduction commands `python3 xenia-rs/zq.py dis …`
  crates/sylpheed-xexdb/SCHEMA.md
                             titled after the retired `xenia-analysis` crate,
                             citing `xenia-rs dis`, pointing at a `xenia-analysis`
                             source path
  sylpheed-xexdb/src/formatter.rs
                             WROTE "generated by xenia-rs" into every disassembly
                             it produced (no test pins the banner)
  sylph-xexdb.rs, db.rs      "SQLite" / "DuckDB writer for xenia-rs"
  sylpheed-formats/src/hash.rs
                             pointed at `xenia-rs/RE_SYMBOLS.md`, now at
                             `docs/re/RE_SYMBOLS.md`

Verified: every rewritten reproduction command was extracted from the doc and
run as written against the regenerated database — all 5 exit 0 and return the
disassembly they describe. The README's function count (25 676) is the database's
own. `cargo fmt --all -- --check` clean.

Not changed, deliberately: the README's Oracle bullet says Canary's native Linux
ELF "crashes / does not run". That is about Canary, not xenia-rs, and it conflicts
with a July note that the native build works — unverified either way here.

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

crates/sylpheed-formats/src/hash.rs

@@ -80,7 +80,7 @@ pub fn name_hash(name: &str) -> u32 {
 
 /// Confirmed TOC key path schemes, as `(prefix, suffix)` around an entry's
 /// internal identity string. The key is `name_hash("<prefix><id><suffix>")`
-/// (backslash separators). Recovered by RE — see `xenia-rs/RE_SYMBOLS.md`.
+/// (backslash separators). Recovered by RE — see `docs/re/RE_SYMBOLS.md`.
 ///
 /// - `("", ".tbl")` — root manifests / DefTables resource entries (`files.tbl`).
 /// - `("unit\\", ".tbl")` — craft/ship definitions (`unit\UN_f001_…_EX5.tbl`).

crates/sylpheed-xex/src/vfs/disc_image.rs

@@ -182,7 +182,7 @@ impl VfsDevice for DiscImageDevice {
 
     fn list_root(&self) -> Result<Vec<VfsEntry>, VfsError> {
         // Return the full flattened tree. Callers of this method are
-        // dump/debug paths (see `xenia-rs dumpxiso`), which want to see
+        // dump/debug paths (the retired `xenia-rs dumpxiso` was one), which want to see
         // every file — root-only was the old flat-enumeration bug.
         Ok(self.entries.clone())
     }

crates/sylpheed-xexdb/SCHEMA.md

@@ -1,7 +1,7 @@
-# `xenia-analysis` schema reference
+# `sylph-xexdb` schema reference
 
 Authoritative documentation for the DuckDB tables and SQL views produced by
-`xenia-rs dis --db sylpheed.db`. Track schema changes here alongside any
+`sylph-xexdb dis <xex|iso> --db sylpheed.db --analyze sql`. Track schema changes here alongside any
 update to the `db_schema_golden` test fixture.
 
 The base + disasm tables (`metadata`, `sections`, `imports`, `functions`,
@@ -162,7 +162,7 @@ or `XENIA_PROBE_DB`; default is `sylpheed.db` next to the .iso when present.
 Resolution happens BEFORE guest exec begins, so it cannot affect the
 lockstep digest.
 
-See `crates/xenia-analysis/src/lookup.rs`.
+See `crates/sylpheed-xexdb/src/lookup.rs`.
 
 ---
 

crates/sylpheed-xexdb/src/bin/sylph-xexdb.rs

@@ -496,7 +496,7 @@ fn cmd_extract(path: &str, output_dir: Option<&str>, db_path: Option<&str>) -> R
         );
     }
 
-    // Write base tables to SQLite if requested
+    // Write base tables to DuckDB if requested
     if let Some(db) = db_path {
         let disasm_info = sylpheed_xexdb::formatter::DisasmInfo {
             image_base: base,
@@ -871,7 +871,7 @@ fn cmd_dis(
         xex_header: Some(&header),
     };
 
-    // SQLite database output (base + ingest + analyze layers)
+    // DuckDB database output (base + ingest + analyze layers)
     if let Some(db) = db_path {
         info!(db = %db, analyze = ?analyze, "writing database");
         let mut w = sylpheed_xexdb::DbWriter::open_fresh(std::path::Path::new(db))?;

crates/sylpheed-xexdb/src/db.rs

@@ -1,4 +1,4 @@
-//! DuckDB writer for xenia-rs.
+//! DuckDB writer for `sylph-xexdb`.
 //!
 //! Layered, streaming writes shared by `extract`, `dis`, and `exec`.
 //! Each command's output is a superset of the previous:

crates/sylpheed-xexdb/src/formatter.rs

@@ -46,7 +46,7 @@ pub fn write_asm(
         out,
         "; ============================================================================"
     )?;
-    writeln!(out, "; Xbox 360 Disassembly — generated by xenia-rs")?;
+    writeln!(out, "; Xbox 360 Disassembly — generated by sylph-xexdb")?;
     if let Some(name) = info.original_pe_name {
         writeln!(out, "; Original PE: {name}")?;
     }