Keep SI fault response running when the follower hangs #64

Parent: #60

Problem

The supervisor and follower/MPC still share a timer and thread. Checking faults before MPC does not help if MPC hangs or overruns: fault detection and stop publication also stop.

Arrival watchdogs use system_clock, so a wall-clock correction can hide a stale source or cause a false fault. These gaps remain after #66 and the heartbeat support in #57.

Done when

• Run fault detection and stop publication on a bounded execution path that does not depend on follower readiness, completion or scheduling. A hung or overrunning follower still produces an observable SI stop through the single supervised output.
• Use monotonic elapsed time for arrival ages and re-enable expiry, separate from source/ROS timestamps. Test forward/backward wall-clock changes without masking stale input, false trips or restarting a completed stop ramp.
• Test selected-source silence, invalid input, stale required feedback and follower hangs. Unrelated publishers and diagnostics cannot refresh the selected source or postpone detection; never switch normal source or mode after a fault.
• Controller-level tests verify latchFault clears earlier re-enable requests, a different fault invalidates a pending request, healthy traffic cannot clear the latch, and explicit re-enable with fresh required sources publishes NORMAL in the clearing tick. Verify fault_id on real ApprovedRequest output.
• Remove the unused input_staleness_gate.hpp and its obsolete test when replacing the old path. Update the contract and record fault-onset-to-detection latency separately from detection-to-applied-brake timing.

References

• Existing supervisor and known hang limitation: feat(si): supervised single output with startup mode selection and native VisionPilot ingress #66.
• Behavior/timing decisions: Finalize the VP–SI control contract #62. Output validation: Bound SI inputs and verify the supervised output #63. Restart/reset recovery: Recover safely after source restarts and time resets #68. Required-source configuration: Configure SI startup and required inputs per deployment #70.

This covers follower failure while SI is running; it does not guarantee a stop if SI, the bridge or the actuator itself stops producing output.