[BUG] plugin entity freeze frame is lost on gateway restart

[bburda]

Steps to reproduce

1. Run the gateway with the OPC UA plugin and the fault manager on its default sqlite store on a persistent volume.
2. Raise an alarm on a plugin app so a fault confirms. Read GET /api/v1/apps/load_process/faults/PLC_JAM_INFEED and note the freeze_frame entry.
3. With the fault still standing, change another value the frame carries (safety_curtain from false to true).
4. Restart the gateway container. Read the fault again.

Expected behavior

The fault keeps the values captured when it confirmed. x-medkit.captured_at does not change.

Actual behavior

The frame is re-read at gateway start:

field	before restart	after restart
x-medkit.captured_at	2026-09-08T18:50:39.873Z	2026-09-08T18:52:13.265Z
data.safety_curtain	false	true
x-medkit.capture_origin	absent	"startup"

first_occurrence and occurrence_count did not change, so the same fault now carries different evidence.

Entity frames live in gateway memory only. The freeze_frames table in faults.db stays at 0 rows. The rosbag recording survives the restart, the frame does not. The new entry keeps type: "freeze_frame" in the same environment_data.snapshots array, so a client gets post-restart state in the shape of a confirm-edge capture.

Environment

• ros2_medkit 0.6.0 (main at f873448), also on a 0.7.0 build
• ROS 2 Jazzy, Ubuntu 24.04

Additional information

#491 persists the fault manager's own frames in the freeze_frames table. #537 and #538 added the zero-config entity frame. #562 and #563 added the startup catch-up. None of them persists the entity frame.

The gateway should keep its entity frames the same way and run the startup catch-up only for faults with no stored frame.