fix(drivers): latch failed Modbus reprobes and keep the old VM

[frahlg]

Accepted text proposal

Issue or Discussion: Follow-up to merged #982 (Fredrik merged without reading the reviews).

Maintainer comment that accepted this scope: Fredrik asked to check those reviews and fix anything that needed it.

What changed

The Modbus give-up reload from #982 now matches the safety boundaries that PR stated but did not implement:

• A failed reload (os.ReadFile / execute / driver_init) sets skipReprobe, so a missing file is not a per-poll loop.
• sawModbusRead is armed only on Successes > 0, not on failed attempts. A device that never answered is not reloaded once its give-up tables go quiet.
• reprobeLocked runs driver_init on the candidate VM before closing the previous one. Init failure restores the old VM so driver_default_mode still has its locals.
• Re-reading the driver file from disk is intentional: catalog drivers are already hot-editable, and this path is a probe retry.

A prolonged outage still retries after give-up. Codex suggested latching after every reload; that would recover a 15-second flap and miss the ~9-minute Pixii blip this path exists to recover.

Why

Reviews on #982 (Codex P1/P2, Bugbot high + two mediums). Human review by miravoss26 said safe to merge, with a non-blocking question about re-reading from disk. The bot findings contradicted #982's own stated boundaries:

• "After a failed reload, reprobe is skipped until the process restarts" — was not implemented.
• "A driver that never successfully read is not reloaded" — Attempts > 0 treated transport failures as success.
• Default-mode after a stale/failed driver must still run (AGENTS.md). Swapping before init left an uninitialized VM.

Boundaries and safety

• Planner output is still never sent directly to hardware.
• Reload still skips driver_cleanup (no setpoint 0 as a recovery side effect).
• A never-online device stays given-up until process restart (as fix(drivers): resume Modbus drivers that give up every register after a network blip #982 specified).
• A long outage keeps retrying; we do not latch after a reload that still made attempts.
• Sign conversion remains at the driver boundary.

Out of scope: changing catalog pixii.lua give-up to ignore transport errors (belongs in srcfl/device-drivers).

Verification

• go test ./internal/drivers/ -count=1 -run 'GiveUp|PixiiRecovers' — pass.
• go test ./internal/drivers/ -count=1 — pass.
• Rebased onto master after #981 and srcfl/ftw-webapp#56, so the catalogue drift check should now compare against app main that has driver.offline / fuse.over_limit.

Checklist

• The diff implements one accepted scope and does not add follow-on work.
• I checked open pull requests that touch the same files.
• Tests cover the changed behaviour and its failure path.
• A human reviewed every changed web/UI view in a browser, or no UI changed.
• A Changeset is included, or the change is exempt.
• Every commit has a DCO sign-off.

  

[cursor]

Not approved: Cursor Bugbot was present but still pending after the 8-minute wait, so the required review signal did not complete. Human review is needed; reviewers were assigned.

  

_{Sent by Cursor Approval Agent: Pull Request Router and Approver}

[miravoss26]

Reviewed. Fixes two real reload-loop bugs in the Lua Modbus give-up path.

What it does:

1. notePollModbusActivity now keys off Successes instead of Attempts — a device that never answers no longer counts as "saw a read," so it stays given-up instead of reload-looping every poll.
2. reprobeLocked now calls driver_init on the new VM before discarding the old one. If init fails, the old VM is kept (so default-mode keeps working) instead of leaving the driver on a half-initialized VM.
3. A failed reprobeLocked call now latches skipReprobe = true — a missing driver file no longer gets retried every single poll.

Correctness: the four new tests exercise exactly the distinction that matters here — failed-reload latches vs. successful-reload-but-device-still-down keeps retrying (the sustained-outage test is a good guard against over-latching, given the Pixii 9-minute-flap note in the comment). Old-VM-kept-on-failed-init is directly asserted via register-read counts staying flat and DefaultMode() still working post-failure.

Security: no secrets, no new deps, no new network destinations, no injection surface change. Pure state-machine fix.

Safe to merge from my read.