b4f19f1f48
This was found UNCOMMITTED in the working tree on 2026-09-14, four days after it was written (file mtimes 2026-09-10 21:01-21:23). It exists in exactly one place and that place was not git: imports.rs / import_address PR #32 (lifted tool): absent iterate-4A (committed): absent working tree: present CONSOLIDATION.md Phase 5 ends with "delete the local clone" and Phase 7 drops the emulator, so this had a deletion scheduled against it. Phase 1's own rule is the reason to commit it: "a retired branch that was never pushed is not retired -- it is deleted, quietly, by someone who thought it was safe." The same applies, more sharply, to work that was never committed at all: Phase 0's gate walks refs/heads, so a dirty working tree is invisible to it. Canary's dirt was secured because someone knew it was there; this was not. Two separable pieces of work: 1. Import-thunk recognition (`imports.rs`, 338 lines new). An XEX import is not a PLT jump: the linker emits a four-word thunk whose first two words are import RECORDS, rewritten by the loader at module load. On disc they are still records, so a PowerPC-only decoder renders them as two meaningless `.long`s before an indirect branch. This maps every word of every thunk -- and every direct branch targeting one -- back to its `imports` row, so disassembly can say `xboxkrnl.exe::RtlEnterCriticalSection` instead of `.long 0x01010194`. Shape-validated, not trusted: an entry is indexed only when the four words it points at actually have the thunk shape. Adds `instructions.import_address` (FK onto `imports.address`) + `import_role` ('record' | 'thunk' | 'call', NULL iff import_address IS NULL) + an index. `zq.py` gains `imp` and `impcalls`, and `dis` names imports. 2. Sixteen schema-wide foreign keys, declared wherever a column is *derived from* another table. CREATE TABLE and insertion order become load-bearing (a parent must exist before any child that references it); `write_analysis_results` documents its order. `functions` is deliberately NOT an FK parent, and the golden test now asserts that: DuckDB implements UPDATE as delete+insert, so an inbound FK would make `functions.name` un-updatable and break apply_re_symbols.sql, which re-applies RE symbol names after every regeneration. Committed exactly as found -- not cleaned up, not rebased. `cargo check` was still running when this was committed; preserving the tree does not depend on it compiling, and editing it first would have destroyed the thing being preserved. Not ported into the lifted `sylpheed-xexdb` crate (PR #32). That is a separate decision for the human: this repo is being retired, and the feature would have to be carried across deliberately. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>