api: make relay outputs hardware-profile aware

docs/cargo-api-contract.md

@@ -183,3 +183,26 @@ Compatibility rule:
 - The API should support the current 2-channel board while allowing a future 6-output profile without changing dashboard/client assumptions.
 - Clients should render outputs dynamically from the API response.
 - Clients should not hardcode relay count.
+
+## Implemented Output Compatibility Layer
+
+The Cargo ESP firmware now exposes relay/output state as an output-count-agnostic list.
+
+The current active hardware profile remains:
+
+    generic_esp32_2ch_relay
+
+The API includes:
+
+- `hardware_profile`
+- `output_count`
+- `relays[]`
+- `relays[].role`
+- `relays[].hardware_channel`
+- `relays[].hardware_profile`
+- `relays[].available`
+- `relays[].state`
+
+This keeps the current 2-channel relay board working while preparing the API shape for the future LilyGO T-Relay-S3 6-way profile.
+
+When the LilyGO board arrives, the expected migration should be a hardware profile and relay driver change, not a dashboard/API redesign.

docs/project-state.md

@@ -263,3 +263,17 @@ Primary goal:
 
 - Keep 2-channel testing functional now.
 - Support future 6-output rendering/control cleanly through the same API shape.
+
+## Output-Count-Agnostic Relay API
+
+The Cargo ESP API now represents relays/outputs as a hardware-profile-aware list instead of hardcoding client assumptions around exactly two relays.
+
+Current active hardware profile:
+
+    generic_esp32_2ch_relay
+
+Future planned profile:
+
+    lilygo_t_relay_s3_6ch_wupp
+
+Current 2-channel testing should continue until the LilyGO board arrives and is bench tested.