docs(gfx): settle render drift as native cmd-buffer op 0x215 (Ghidra), align docs

Read op 0x215's real handler FUN_0042a0b0 (resolved via the dispatch table
ctx[0x26c93+op]; Kelebek's 0x421160 is VA-drift). It writes cmd-type 5 into the
current gfx-object record and returns a std::map::find over an engine-internal
registry populated by sibling gfx ops (0x1a2 hash insert). The return is native
command-buffer state, not the VM global bank -> seeding story-state cannot fix
the drift. Verdict: (b) a genuine native op, NOT (a) state-divergence.

Reconcile the previously contradictory drift accounts onto one canonical home
(engine-re.md op 0x215), with opcodes.toml carrying the opcode-level semantics
and phase-a-slice-plan / tools-reference / frida README corrected to point at it
instead of repeating the disproven state-divergence conclusion.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

tools/frida/README.md

@@ -28,7 +28,8 @@ Prereq: `py -3.11 -m pip install frida` (core only — `frida-tools` CLI is not
   region (~30 MB, nonstable base). Attach → it enumerates ranges, dumps the module image + every r-x
   range ≥ 1 MB (chunked) → `build/engine-dump/{manifest.json,range_<base>.bin}`, and prints the
   landmark bytes at `AGE.EXE+0x74f1f` to validate. Then disassemble (capstone) and locate a handler
-  (e.g. `0x215` @ Kelebek VA `0x421160`) via the opcode dispatch table. Attach by pid.
+  (e.g. `0x215` → real handler `0x42a0b0`, resolved via the opcode dispatch table — Kelebek's `0x421160`
+  is VA-drift, an unrelated fn). Attach by pid.
 - **`capture_load_order.py`** — ★ the working asset-resolution capture. Hooks `ReadFile` on
   `DATA2.ALF`; each asset load starts with header reads **at its exact archive offset**, so exact-start
   reads give the clean per-asset **load order** (→ names via `build/asset-index.json`). `--analyze`