fix(gateway): freeze-frame the faults that were already raised at startup

[mfaferek93]

Closes #562.

Plugins start reporting during GatewayNode construction, while the capture is
wired later from main.cpp (it needs the shared subscription executor, which is
built after the node). A device that is already in fault confirms in that window,
its EVENT_CONFIRMED is published to nobody, and since the capture only fires on
the confirm edge the fault stays frameless for as long as it is raised.

capture_standing_fault_frames() runs once the capture is live: it lists the
confirmed faults and enqueues a capture for each fault that has no frames yet.
Frames are process-local, so this restores what the missed edge would have
produced rather than duplicating anything, and capture_missed_fault() is a
no-op when the live event already captured the fault.

It runs detached, after wait_for_services with a bounded timeout, so startup
never blocks on the fault services being up. The synthetic event goes through the
same queue and worker as a real one, so the backlog bound and the plugin-call
threading rules are unchanged.

Worth naming: a frame captured this way holds the values at catch-up time, a
second or so after the confirm, not the values at the confirm itself. For a fault
that is standing at boot that is the only honest option - the earlier values no
longer exist anywhere.

[Copilot]

Pull request overview

This PR addresses a startup race in the gateway where faults that are already CONFIRMED at boot can miss their entity freeze-frame capture because the /fault_manager/events subscription is wired after plugins begin reporting faults.

Changes:

• Add a startup catch-up path (capture_standing_fault_frames()) that lists currently confirmed faults after the capture is initialized and enqueues synthetic confirm events for frameless faults.
• Add EntityFreezeFrameCapture::capture_missed_fault() to enqueue a synthetic confirmed fault event through the existing bounded queue/worker.
• Expose the new catch-up helper on GatewayNode and document the intended “missed confirm” behavior in headers.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 4 comments.

File	Description
src/ros2_medkit_gateway/src/gateway_node.cpp	Wires a detached startup catch-up thread to list confirmed faults and enqueue missed captures.
src/ros2_medkit_gateway/src/entity_freeze_frame_capture.cpp	Adds capture_missed_fault() to synthesize confirm events into the existing capture queue.
src/ros2_medkit_gateway/include/ros2_medkit_gateway/gateway_node.hpp	Declares the new capture_standing_fault_frames() method on GatewayNode.
src/ros2_medkit_gateway/include/ros2_medkit_gateway/entity_freeze_frame_capture.hpp	Documents and declares capture_missed_fault() for missed-confirm catch-up.

[bburda]

Additional findings outside the diff:

• Would you add a launch test for this? create_test_launch always starts the gateway first, so test_entity_freeze_frame.test.py cannot reach the new path and the lister always sees an empty list. Starting the fault manager first, holding a confirmed fault, would prove the fix, and that test fails on main.
• Could you update the docs? docs/tutorials/snapshots.rst and docs/config/server.rst describe freeze frames as captured "when the fault confirms", and docs/tutorials/snapshots.rst and docs/api/rest.rst describe freeze_frame as "captured at fault confirmation". None of them mention the startup catch-up, and the value-age caveat from your description is not written down anywhere a user would see it.
• Could you extend REQ_INTEROP_088 in docs/requirements/specs/faults.rst? Its text ties capture to the confirm event, but both new tests verify the startup trigger.

[mfaferek93]

The outside-diff items:

• New e2e test_standing_fault_freeze_frame.test.py: the fault manager starts first, a seeder confirms a fault and exits, the gateway starts after and must serve the freeze_frame with capture_origin startup and the seeded values - 76af95e, three green runs.
• snapshots.rst, server.rst and rest.rst document the catch-up, the captured_at semantics and the origin marker; the REQ_INTEROP_088 text now covers the startup case - 3a1857c.