app: 'd' — define typed data in the listing (make_data, M3)

Press 'd' on a listing head to define typed data at that address via a prompt
(the ".data type definitions" backlog item). Mirrors the retype prompt flow:
MakeDataRequested -> #makedata Input (prefilled with a size-appropriate default
type: unsigned __int8/16/32/64 or char[N]) -> _do_make_data worker ->
Program.make_data -> bump_items -> reopen the listing in place. Accepts any C
type IDA's SetType understands: int, char[16], my_struct, T *arr[4], ...

Pilot: listing_view gains a deterministic sub-test — undefine a data head to
synthesize an unknown run, assert it renders as `unknown`, then 'd' char[4]
over it and assert it becomes a `data` head. 118 pass / 1 pre-existing flaky
(filter); rpc_smoke 29/0.

1 files changed, 6 insertions, 3 deletions

diff --git a/TODO b/TODO
index 92ecfa1..935fc24 100644
--- a/TODO
+++ b/TODO
@@ -25,9 +25,12 @@ hard:
     -> M2 done: ListingView — virtualized flat listing (code+data+undefined,
        kind-styled), wired into nav/follow/xrefs/hex/edit-verbs. region views
        now use it (not the DisasmModel stopgap).
-    -> next: M3 data typing in .data (`d`/make_data with a type prompt, struct-
-       typed data, string/dup coalescing for big undefined runs); M4 optionally
-       unify the function disasm view as a filtered listing.
+    -> M3 done: `d` = typed make_data prompt in the listing (define data in
+       .data with any C type: int, char[16], my_struct, ...); undefined byte
+       runs coalesce into `db N dup(?)` rows so big .bss doesn't explode.
+    -> next (optional): M4 unify the function disasm view as a filtered listing;
+       struct-typed data expansion / string auto-detection; back-paging in the
+       ListingModel (currently loads a segment forward via load_all).
 
 crazy:
 [ ] multi/split view ala ghidra?