arm encoder: not fuzz-total — arithmetic underflows + empty seed corpus make encoder_no_panic flaky

[avrabe]

Summary

The encoder_no_panic fuzz target finds a class of pre-existing encoder totality gaps (all present on main). The harness contract is "encode() returns Ok or Err on every ArmOp, never panics," but several paths panic under -Cdebug-assertions:

1. PC/R15 operand → verify_reg_bits debug_assert. Fixed in PR fix(encoder): high-register Thumb ADD/ADDS/SUBS use 32-bit .W — root-cause #180, re-enable optimized memory path #183 (arm encoder: panics (debug_assert) on PC/R15 operand instead of returning Err — fuzz-found, pre-existing #185) via reg_bits_checked → typed Err.
2. Arithmetic underflow at arm_encoder.rs:509 — ARM32 BCondOffset does *offset - 2 ("account for PC+8"); a small/negative offset underflows and panics. Likely siblings in other offset-arithmetic paths (BOffset, Bl).

Because the fuzz target has an empty seed corpus, each 60s CI run explores different random inputs, so it surfaces a different pre-existing panic intermittently — making Fuzz Smoke flaky. (Branch protection does not require it, which is why prior releases merged through the flakiness.)

Done when

• Offset-arithmetic encoders use checked/saturating ops and return Err (or clamp) instead of panicking on out-of-range offsets.
• A committed seed corpus under fuzz/corpus/encoder_no_panic/ (CI currently logs "0 files found in corpus"), so the gate is deterministic.
• Optionally: a totality audit of encode() (every as/index/sub on fuzz-reachable fields) so encoder_no_panic is reliably green.

Context

Found while fixing #180/#185 (the high-register ADD truncation + the PC-operand panic). Those two are landed; this issue tracks the remaining totality work as a separate effort rather than expanding the #180 bugfix PR unboundedly.