Add 'annotate-usecode' command to import USECODE IR JSON annotations

- Introduced a new command 'annotate-usecode' to import USECODE IR JSON annotation hints as Ghidra comments on compiled anchors.
- Added argument parsing for multiple IR JSON files, comment type selection, and a dry-run option.
- Implemented logic to read annotation records from the provided IR files and set comments on the corresponding addresses in Ghidra.
- Enhanced JSON schema to include response structure for the new command.

docs/raw-000e.md

@@ -67,7 +67,13 @@ A small helper cluster in the raw `000e:` area implements a fixed-size CRLF reco
 	- the trigger/object namespace now clearly includes `JELYHACK`, `NPCTRIG`, `CRUZTRIG`, and `TRIGPAD`
 	- `JELYHACK` / `JELYH2` sit in a local extraction neighborhood beside `SPECIAL`, `TRIGPAD`, `DATALINK`, `HOFFMAN`, `REE_BOOT`, `SURCAMEW`, and `SFXTRIG`, which looks more like a map/object grouping than random table order
 	- that neighborhood does not make `JELYHACK` itself event-bearing, but it does place it immediately beside multiple event-capable or trigger-adjacent classes (`REE_BOOT`, `SFXTRIG`, `SURCAMEW.eventTrigger`)
-	- no extracted chunk has yet been tied directly to event `0x410`
+	- the requested descriptor-family sweep now sharpens the nearby callable-body picture too: `NPCTRIG` is the only requested family here that is both explicitly event-bearing and non-empty in `class_event_index.tsv` (`equip` at slot `0x0a`, plus anonymous slot `0x20`), while `SPECIAL`, `TRIGPAD`, and `REB_PAD` have callable bodies but still look like state/controller or referent-neighbor records rather than direct event carriers
+	- the new generated `immortality_target_body_scan.md` / `.tsv` report now scans `EVENT`, `NPCTRIG`, `COR_BOOT`, `REE_BOOT`, `SFXTRIG`, `SPECIAL`, and `TRIGPAD` body windows directly for inline little-endian `0x0410`, dword `0x00000410`, and byte-swapped `0x1004`
+	- that scan found zero literal hits in every currently targeted body, so no extracted target body is yet tied directly to event `0x410` by immediate-value evidence
+	- the `TELEPAD` slot-`0x20` row with `raw_code_offset = 0x00000410` in `class_event_index.tsv` is now closed as an offset collision, not proof that `TELEPAD` emits gameplay event `0x410`
+	- the new body scan also narrows the frontier structurally: `EVENT` remains one monolithic slot-`0x0a` body (`8150` bytes), `NPCTRIG` remains the strongest compact trigger frontier with slot `0x0a` (`373` bytes) plus slot `0x20` (`345` bytes), and `_BOOT` slot pairs (`COR_BOOT`/`REE_BOOT`) stay near-template bodies rather than unique immortality emitters
+	- `SPECIAL` and `TRIGPAD` are now stronger negative controls too: both still have callable bodies, but the new literal scan found no inline `0x410` evidence there either
+	- the practical blocker is now narrower: the extractor no longer stops at body offsets only, but it still does not decode emitted payload values or bytecode operands inside the surviving `EVENT` slot-`0x0a` and `NPCTRIG` slot-`0x0a` / `0x20` frontier bodies
 	- one exact `0x410` collision in compiled code is now explained away: `000e:0953` pushes `0x410` into imported `ASYLUM.27` from the animation audio-subframe path immediately after setting the local audio-completion byte at `+0xef1`. Since `ASYLUM.DLL` is the `ASS_*` audio/media library, treat this as a media ordinal/value collision rather than a second gameplay or USECODE event source.
 	- the present best reading is that `0x410` is likely carried by data relationships between generic event-capable descriptors (`EVENT`, `NPCTRIG`, `SFXTRIG`, etc.) and map/object references rather than by a plain-text script line
 - The `000e:` record parser helpers still matter, but they now appear to cover only the text-oriented subset rather than the entire FLX payload. The strongest concrete caller so far is the raw window at `000e:1b9f..1d49`, where `record_table_parse_buffer` is invoked after setup of fields that match the known animation object layout (`+0x117/+0x11b/+0x11f/+0x123`, `+0xeaf/+0xeb1`, `+0x10f/+0x111`). That makes the currently verified `000e:3639` consumer part of the animation-object lane, not a clean standalone EUSECODE loader.
@@ -198,6 +204,10 @@ The game uses standard RIFF/IFF:
 ### Unresolved callee
 
 - `000e:ffb0` remains unresolved (decompiles garbled due to overlapping instructions at `000f:0085/000f:0086`). Current evidence from the `animation_start` loop suggests this path is the video-side subframe loader paired with `anim_load_audio_frame`.
+- The caller-side proof is now explicit enough to preserve that note in Ghidra too: `animation_start` invokes `anim_load_video_frame_wrapper` once per active subframe immediately after `anim_load_audio_frame`, and `anim_load_video_frame_wrapper` is only a thin forwarder to `000e:ffb0`. Until the overlap is repaired, the safest label remains `unresolved video-side subframe loader paired with the resolved audio-frame path`.
+- A second caller pass tightens the local model without forcing a repair. `search_instructions` now shows `anim_load_video_frame_wrapper` is also called at `000e:11af` and `000e:1245`, not only from the startup prime loop at `000e:220c`. In both of those additional windows the return value is checked as a success/failure result, which makes `000e:ffb0` look like an active chunk-consume/decode step rather than a passive notifier.
+- The strongest new evidence is the neighboring tag gate at `000e:121d..1234`: after `anim_load_audio_frame` runs, the same lane checks the current RIFF chunk tag against `0x62643030` / `0x63643030` (`"00db"` / `"00dc"`) before clearing the local busy flag and continuing. That is the first concrete caller-side clue that `000e:ffb0` is consuming AVI video-frame chunk types rather than some unrelated animation-side bookkeeping path.
+- Boundary analysis still reports one overlapped function object `FUN_000e_ffb0 @ 000e:ffb0 body 000e:ffb0 - 000f:00e0`, so the function remains comment-only for now. The useful gain is semantic: the unresolved body is now best described as `video-side subframe loader/decoder for the 00db/00dc chunk lane, paired with anim_load_audio_frame`.
 
 ### Constructor pattern