arm: switch ARM/Thumb decoding with `t`

`c` could not carve Thumb code. Thumb isn't a property of the bytes — it's a
mode the CPU is in — so a raw image gives IDA nothing to detect: at a Thumb entry
point it decodes 16-bit instructions as 32-bit ARM and produces confident
nonsense. experiments/fibonacci.bin starts with `08 b5` = push {r3,lr}, which
IDA reads as SVCLT 0xBF00.

`t` on the listing switches the mode at the cursor and disassembles in it:

  Thumb @ 0x0 (segment set to 32-bit; Thumb needs ARM32) — 10 instructions
  0x0 PUSH {R3,LR}   0x2 MOVS R1, #0   0x4 MOV R4, R0   0x6 BL unk_E3C

Setting the T segment register is only half of it. Thumb does not exist in
AArch64, and a headerless blob loaded with -parm comes up 64-bit, so T alone
changes nothing and looks broken — I watched exactly that happen while probing
the API. Asking for Thumb IS asking for ARM32, so set_thumb forces the segment
to 32-bit and says so rather than doing it silently.

It also has to del_items over the range first: the bytes are currently decoded
in the old mode, and leaving that item defined pins the wrong instruction length
so the new mode has nothing to apply to.

Implemented as a `thumb` kind in the existing edit-item flow, so it inherits the
shared reload — same cache bump, same ViewAnchor restore, same status flash. It
switches AND disassembles, because flipping T and leaving the bytes undefined
shows you nothing and reading the code was the point.

tests: new tests/test_thumb_ui.py (8) driving the real Thumb binary — `c` alone
does NOT produce the prologue, `t` does, the instructions are 16-bit wide (in ARM
mode those three rows would be one 4-byte instruction), the run continues, the
status explains the 32-bit forcing, and `t` toggles back. Deletes the .i64 first,
because T and the segment's addressing mode are saved in it and a stale database
would answer the question for us.

209/0 scenarios, 26/0 blob, 8/0 thumb.

1 files changed, 20 insertions, 0 deletions

diff --git a/docs/PROJECTS.md b/docs/PROJECTS.md
index 10274ab..38d3262 100644
--- a/docs/PROJECTS.md
+++ b/docs/PROJECTS.md
@@ -297,6 +297,26 @@ conversion happens in `BinaryRef.load_args`, and a base that isn't 16-byte
 aligned is rejected rather than silently landing somewhere else. `ida_args`
 passes anything else through untouched.
 
+### ARM/Thumb
+
+Thumb is not a property of the bytes — it's a mode the CPU is in — so a raw image
+gives IDA nothing to detect. At a Thumb entry point it decodes 16-bit
+instructions as 32-bit ARM and produces confident nonsense: `push {r3,lr}`
+(`08 b5`) reads as `SVCLT 0xBF00`, and `c` either refuses or carves garbage.
+
+`t` on the listing switches the mode at the cursor and disassembles in it:
+
+    Thumb @ 0x0 (segment set to 32-bit; Thumb needs ARM32) — 10 instructions
+
+It sets IDA's `T` segment register, and forces the segment to 32-bit when
+turning Thumb on. That second part isn't optional: Thumb doesn't exist in
+AArch64, and a headerless blob loaded with `-parm` comes up 64-bit, so setting
+`T` alone changes nothing and looks broken. Asking for Thumb *is* asking for
+ARM32.
+
+`t` again toggles back — the mode is a guess, and guesses get revised. Both
+states are saved in the `.i64`.
+
 ### When analysis finds nothing
 
 Zero functions is what a raw image described wrongly looks like — right file,