DF-5461 — ichsmb_wait timeout path leaves the transaction running and re-arms stale completions (trace-only pack)

ichsmb_wait() (ichsmb.c:629-654) sleeps exactly once for hz/4; on EWOULDBLOCK it prints, sets sc->ich_cmd = -1 (ichsmb.c:646) and returns SMB_ETIMEOUT — but the host controller transaction is never aborted: - ICH_HST_CNT_KILL (ichsmb_reg.h:80) is never written anywhere in the driver, - HST_STA is not reset, the controller can remain HOST_BUSY. A completion that lands after the timeout is then processed with ich_cmd == -1 (unexpected-irq path, ichsmb.c:529-535: cleared + logged), or — if a new command was already started — is mis-attributed to it (ok_bits match at ichsmb.c:521-528), waking ichsmb_wait for a transaction still in flight: the new op returns SMB_ENOERR with stale/zero data (silent data corruption; e.g. security-relevant sensor/IPMI reads), after which the real completion is discarded as unexpected. ig4-family siblings: DF-5386 (error swallowed as success) and DF-5389 (stale state leaks into the next transaction).

Not verified live: the rig's slaves always complete promptly and QEMU offers no way to stall an SMBus transaction past hz/4. Trace-confirmed; severity Low. Fix sketch: on timeout, write ICH_HST_CNT_KILL | INTREN, clear HST_STA, drain before returning; use a generation counter so late completions can't satisfy a newer wait.