Standardize vendor fields on SOVD-endpoint payloads as nested x-medkit object

[bburda]

Summary

We want one consistent convention for vendor fields on SOVD-standard endpoint payloads: nested "x-medkit": { ... }. Today that rule is broken in at least one place: GET /updates/{id}/status emits the vendor phase as a flat top-level key "x-medkit-phase" instead of "x-medkit": { "phase": "..." }. Surfaced during review of selfpatch/ros2_medkit_web_ui#72 (new typed client-side support for that field).

Other SOVD-endpoint payloads already follow the nested convention (examples from existing handlers and transforms):

• Faults collections: "x-medkit": { "count": N }
• Data / operations detail: "x-medkit": { "ros2": { "kind": "...", "topic": "...", "type": "..." }, "access": "read|write", "entity_id": "..." }
• Bulkdata: "x-medkit": { "fault_code": "...", "duration_sec": 5.0, "format": "mcap" }

Proposed solution

1. On SOVD-standard endpoint responses, move all x-medkit-* flat top-level vendor keys into a nested x-medkit object. Concrete case today: GET /updates/{id}/status emits { "x-medkit": { "phase": "prepared" } }.
2. Reflect the change in schema + docs (docs/api/rest.rst, OpenAPI spec).
3. Downstream clients update type + readers in lockstep (web UI, MCP server, foxglove extension, generated clients).

Out of scope

• Vendor-extension endpoints like /apps/{id}/x-medkit-param-beacon. That route lives under the OpenAPI x-<vendor>-<name> namespace and its payload is fully vendor-owned, so the nesting rule does not apply there.
• Capability / route naming - not affected.

Additional context

Existing nested examples for reference:

• src/ros2_medkit_gateway/src/http/handlers/fault_handlers.cpp (faults x-medkit.count)
• src/ros2_medkit_gateway/src/http/handlers/data_handlers.cpp, operations_handlers.cpp (x-medkit.ros2.*, x-medkit.access, x-medkit.entity_id)
• src/ros2_medkit_gateway/src/http/handlers/bulkdata_handlers.cpp

Flat cases to migrate (non-exhaustive):

• src/ros2_medkit_gateway/include/ros2_medkit_gateway/updates/update_types.hpp - x-medkit-phase on GET /updates/{id}/status

[bburda]

Adjacent finding worth folding into the same refactor (or splitting if scope grows): the underlying UpdatePhase enum collapses prepare-failure and execute-failure into a single Failed value. A UI consuming x-medkit.phase cannot distinguish 'failed during prepare' from 'failed during execute' from the phase alone - it has to text-match error_message to dispatch.

Concrete change in include/ros2_medkit_gateway/updates/update_types.hpp:

• Extend UpdatePhase with PrepareFailed and ExecuteFailed variants. Generic Failed stays as a fallback.
• Update update_phase_to_string mapping with the two new strings.
• In src/updates/update_manager.cpp: prepare-side failure paths (around lines 335, 348, 361) set PrepareFailed; execute-side (around 391, 404, 417, 445, 471, 484, 497) set ExecuteFailed.
• Add test_update_manager.cpp assertions for the two new values on the corresponding failure paths.

Estimated ~30-50 lines + tests. Naturally pairs with the nested-vendor refactor in this issue since both touch the same field on the same endpoint - one PR can land both, or split into two if the nested move is closer to being ready.