Framework code and the address table disagree on eight values #16

Naming every address from addresses.toml showed places where the framework and the table disagree on what a value means. The names follow the table; the code's values are unchanged, so each one is either a bug in the code or an error in the table.

1. 0x09998D50: the code (mhfu_world_player_pos, nameplates, freecam) treats it as the camera's look-at, the player's position. The table says it is the camera eye (CAM_VIEW_EYE), with the look-at at 0x09998D60. freecam writes the look-at there. Settled: the table is right, the eye sits ~490 units from the hunter (mhfu.player_pos returns the camera eye, not the hunter #26), and the code fix is mhfu.player_pos returns the camera eye, not the hunter #26.
2. 0x09998E10: the code calls it eye − target; the table (CAM_OFFSET) says look-at − eye.
3. ENTITY+0x334: the code calls it the AI state (u8, 2 = engaged), and force_aggro, the Lua ai_state binding and combat's clone log use it that way. The table says ANIM_SPEED, u16[3].
4. ENTITY+0x364: entity.cpp writes a combatant index; per the registrar it holds COMBAT_NODE + 0x1C.
5. Likely memory corruption: entity.cpp and lua_host's combat.cpp copy 0x110 bytes per collision node, but the builder they call allocates 0xE0-byte nodes, so each copy runs 0x30 bytes into the next.
6. Entity size: entity.cpp clones 0x7A00 bytes; em_vhook bounds stores to 0x800, what the em factory allocates.
7. Screen state 22 is taken as the village (MHFU_WORLD_SCREEN_VILLAGE; it gates the volatile interposer). The table and the automation notes say the village reads 0 or 113. Settled: 22 is the boot's load around the save read, the village 0 or 113 (six cold boots, feat(framework): village NPCs of our own, and a Zinogre that follows the hunter #62); the ms0 gate that still opens on 22 is Log, hot reload and the spawn poll pause for the whole village #22.
8. 0x09B661E8 (TIGREX_ATTACK_SPAWN): lua_host calls it the per-frame combat-node builder; the table says it spawns an attack volume. Settled: the table is right; it spawns an attack node by attack id, and the move player spawns our attacks through it (feat: hybrid ports wave 2: studio clips, walking, hit push, every clip in game, engine walls #52, Hybrid ports wave 3: the move player, travel, turns and walls, lane screenshots #55). lua_host's clone path still uses it as a node builder.

Unsettled fields: QUEST_TARGET.MEMBER_FLAGS, QUEST_LIST_NODE.FLAG/RESERVED, CAM_VIEW_MATRIX and CAM_PROJ_MATRIX 0x80 apart, and lua_host's vt[0x3C].

• Settle each on a running game, and fix whichever side is wrong
• 5 first: measure the node size and copy that many bytes

Done when the code and the table agree on every item above.

Landed in #52 (item 8) and #62 (item 7).