1.6.3 — housekeeping: dead code, build string, FSM model

Housekeeping release: two things left over from the round 4 and 5 campaigns, and
the build string fix for 1.6.2.

Build string

VERSION moved to 1.6.2 while SL4A_DRIVER_VERSION in the driver stayed at
1.6.1, so anything that reported the build (the sysfs attribute read by
tools/sl4a-touch.sh logs) said v1.6.1. The host test that compares the two
caught it on main (the 1.6.2 release commit failed CI for exactly this), and
bumping both is part of the release steps now. This release ships the corrected
string: build_info reports v1.6.3.

Dead code

Round 4's inventory listed the driver state no code path can reach. It is deleted
rather than annotated, so the next reader does not have to prove its innocence
again:

• reset_work / spi_hid_reset_work() and reset_pending: no schedule site
  existed, so the flag it set was never observed true and the two branches that
  read it were dead. The live device reset is the sequencer's own recovery.
• refresh_device_work / spi_hid_refresh_device_work() and
  refresh_in_progress: the report-descriptor refresh worker was never queued and
  its flag had no reader either.
• keep_powered: six writes, zero reads. Suspend-time power gating needs an
  implementation, not a field.

The trace events for both workers stay in spi-hid_trace.h (tracing ABI, zero
cost when unused), and the unreachable VENDOR_INIT handler stays with its
raw-mode gates: it documents a state of the decompiled protocol map, and those
gates are correct if that state is ever wired up.

Slot state machine model

The per-slot FSM in raw_pipeline_math_test.c had drifted from the driver in
four places: hold entry consulted the blob weight (the driver holds on the first
missed frame whatever the weight), hold expiry fired one frame late, and both
re-claim branches restarted duration at 0 instead of 1. The model is aligned
with the driver and its file now says out loud that it is documentation: a
regression in the driver will not fail there, the behavioural checks live in
raw_pipeline_replay_test.c, which links the real pipeline.

Checks

make -C tests test and make -C tests SANITIZE=1 test are green, and both model
divergences were falsified: reintroducing either the weight condition on hold
entry or the late expiry makes the suite fail, so the expectations bite.

Not yet testable here: this release has not been run on SL4/SL3 hardware.

---

Field result (2026-09-15, Surface Laptop 4 AMD, Zorin): the standard HID profile
works normally, and the raw profile works with one and two fingers. A third finger
reads as weak; that is being investigated offline before the next release.
The paragraphs above are unchanged: nothing here has been run on SL3, and the
opt-in switches still need their own field data.