[BUG] Lifecycle status operationIds are pluralized (getAppsStatus), inconsistent with singular convention

[bburda]

Bug report

Steps to reproduce

1. Export the OpenAPI spec from a 0.6.0 gateway (GET /api/v1/docs).
2. Inspect the operationId values for the entity lifecycle status routes (/apps/{app_id}/status*, /components/{component_id}/status*).

Expected behavior

The lifecycle status operationIds follow the same singular entity-name convention as every other entity route (getApp, getAppDataItem, getAppOperation, ...): getAppStatus, putAppStatusRestart, getComponentStatus, etc.

Actual behavior

They are pluralized: getAppsStatus, putAppsStatusRestart, getComponentsStatus, ... This is inconsistent with the rest of the spec and produces awkward generated client function names (e.g. get_apps_status in the Python client).

Root cause - the lifecycle route registration in src/ros2_medkit_gateway/src/http/rest_server.cpp builds the operationId from the plural collection name instead of the singular entity name:

const std::string entity_cap = capitalize(std::string(et_lc.first));  // et_lc.first = "apps"/"components" (plural)
...
.operation_id(std::string("get") + entity_cap + "Status");            // -> getAppsStatus
.operation_id(std::string("put").append(entity_cap)...);              // -> putAppsStatusRestart

Every other route uses capitalize(et.singular). The same loop already has the singular form available as et_lc.second ("app"/"component") and uses it in .summary(...).

Suggested fix: build the operationId from the singular form, i.e. capitalize(et_lc.second).

Environment

• ros2_medkit version: 0.6.0
• ROS 2 distro: any
• OS: any

Additional information

Noticed while regenerating the OpenAPI clients for 0.6.0 - the pluralized names propagate to the generated/curated client surface. Low severity (the endpoints work; only the operationId names are inconsistent). Note that fixing this renames the generated client functions, so it is cheapest to apply before consumers depend on the current names.