decoder: tell it about the reference assets, and that the DB can be wrong

The mounts landed but the agent could not learn of them: I documented them in
CONTAINER-NOTES.md, which the decoder's prompt does not list, and then restarted
the container -- so a fresh session with no memory of the exchange had a 586 MB
database and a decompressed image sitting unmentioned in its filesystem.

Now in the PROMPT itself, not only in a document, because the prompt is the one
thing a new session is guaranteed to read. CONTAINER-NOTES.md is also added to
its reading list.

And the caveat that matters more than the asset. The .pe is PRIMARY -- the bytes
the console executed. The database is somebody's ANALYSIS of them, produced by a
disassembler that had to guess, and it is wrong in the ways disassemblers are
wrong: misdecoded mnemonics where data was read as code, function boundaries
short or long or merged or split, coverage missing entirely for code reached only
by indirect dispatch, and names that are derived rather than symbols.

So a finding resting on a database row is not established until the bytes agree:
read the same address out of the .pe and check. Where they disagree the image
wins, and the disagreement is itself worth recording, because it tells the next
reader which parts of the database to distrust.

A fast index into 9.2 MB of machine code, not a source of truth.

docs/agents/CONTAINER-NOTES.md

@@ -95,6 +95,28 @@ indirect_dispatch_candidates 1 827 297  dispatch_pc, vtable_address, method_addr
 `instructions.raw` is an **INT, not hex** — a trap this corpus has already paid
 for. Query with `python3 -c 'import duckdb'`; it is not SQLite.
 
+### ⚠️ It is derived data, and it is wrong in places
+
+The image is **primary** — those are the bytes the console executed. The database
+is **an analysis of them**, produced by a disassembler that had to guess, and it
+fails the way disassemblers fail:
+
+* **misdecoded mnemonics** — data read as code, or a decoder-table gap, produces
+  a plausible instruction that was never executed as one;
+* **wrong function boundaries** — `end_address` short or long, neighbours merged,
+  one function split in two;
+* **incomplete coverage** — code reached only through indirect dispatch may be
+  absent entirely; the 1.8 M `indirect_dispatch_candidates` are *candidates*;
+* **invented names** — largely derived rather than symbols, so a name is a
+  hypothesis wearing a label.
+
+**A finding resting on a database row is not established until the bytes agree.**
+Read the same address out of the `.pe` and check. Where they disagree the image
+wins, and the disagreement is worth recording — it tells the next reader which
+parts of the database to distrust.
+
+It is a fast index into 9.2 MB of machine code. It is not a source of truth.
+
 ### These mounts are reference material, not a deliverable
 
 They are read-only and they come from outside the repository, which means a

docs/agents/decoder-loop.md

@@ -38,6 +38,52 @@ If the merge conflicts, resolve it, say so in your reply, and carry on.
 6. `docs/re/INDEX.md` — what is decoded. Re-deriving a ✅ row is not a finding.
 7. `docs/game/navigation.md` — how the game is navigated, **from the player's
    side**. Fill it in as you go: you are the one who sees the real screens.
+8. `docs/agents/CONTAINER-NOTES.md` — the container's tooling, and the reference
+   assets described below.
+
+## Reference assets you may not know you have
+
+Your session is new each time the container restarts, so this is repeated here
+rather than left in a document you might not reach.
+
+| path | what | env |
+|---|---|---|
+| `/image/sylpheed.pe` | the decompressed executable image | `SYLPHEED_PE` |
+| `/xenia-rs/sylpheed.db` | a disassembly database, 586 MB | `SYLPHEED_DB` |
+| `/disc` | the extracted disc | `SYLPHEED_DISC` |
+| `/iso/game.iso` | the retail ISO Canary boots | `SYLPH_ISO` |
+| `/canary` | the Canary source, read-write | `XENIA_SRC` |
+
+**The `.pe` is a flat VA dump**: file offset = `VA - 0x82000000`. Reading
+`0x820A1630` is `seek(0xA1630)`. No XEX decrypt, no LZX, **no booted emulator** —
+dumping guest memory works but makes the whole static corpus depend on a running
+game, and it does not have to. An earlier claim that this file was *stale* was
+tested and **refuted**; it is current.
+
+The database holds 25 481 functions, 851 classes with RTTI, EH tables, imports,
+1 526 function-pointer arrays and 1.8 M indirect-dispatch candidates. Query it
+with `duckdb` — it is not SQLite. `instructions.raw` is an **INT, not hex**.
+
+### ⚠️ The database is derived, and it can be wrong
+
+The image is **primary**: those are the bytes the console executed. The database
+is **somebody's analysis of them**, produced by a disassembler that had to guess,
+and it is wrong in the ways disassemblers are wrong:
+
+* **Mnemonics can be misdecoded** — data read as code, or a decoder-table gap,
+  yields a plausible instruction that was never executed as one.
+* **Function boundaries can be wrong.** `end_address` may be short or long;
+  neighbouring functions may be merged, or one split in two.
+* **Coverage is incomplete.** Code reached only through indirect dispatch may not
+  appear at all — the 1.8 M `indirect_dispatch_candidates` are *candidates*.
+* **Names are largely derived, not symbols.** A name is a hypothesis with a label.
+
+So: **a finding that rests on a database row is not established until the bytes
+agree.** Read the same address out of the `.pe` and check. Where they disagree,
+the image wins and the disagreement is itself worth recording — it tells the next
+reader which parts of the database to distrust.
+
+Treat it as a fast index into 9.2 MB of machine code, not as a source of truth.
 
 ## The oracle