feat: complete plugin↔monitor bridge integration

- Update submodule refs for Monitor and Plugin
- Mark plugin↔monitor bridge TODO items as complete in cross-project todo
- Sections 4.6, 5.1-5.4, Phase A/E bridge items all done

plans/hf-cross-project-todo.md

@@ -18,7 +18,10 @@
   - current CLI contract: `--json` emits raw success payloads on stdout without a universal envelope; list/get responses should preserve canonical code-bearing fields when backend payloads provide them
 - [x] Define CLI exit code / stderr conventions
   - current CLI contract: success exits `0`; validation/runtime failures exit `1`; errors go to stderr and successful output goes to stdout
-- [ ] Define local plugin↔monitor communication protocol over `monitor_port`
+- [x] Define local plugin↔monitor communication protocol over `monitor_port`
+  - Monitor exposes `GET /health`, `GET /telemetry`, `POST /openclaw` on 127.0.0.1:MONITOR_PORT
+  - Plugin pushes OpenClaw metadata via POST /openclaw; Monitor enriches heartbeats with received data
+  - All communication is optional/degradable — both sides function independently
 - [ ] Define release order across submodules
 - [ ] Define rollback strategy if plugin / monitor bridge is unavailable
 
@@ -267,7 +270,7 @@
 
 ### 3.4 Monitor UI alignment
 - [x] Ensure monitor views expose server identifier/code cleanly
-- [ ] Review display of OpenClaw/plugin metadata once Monitor bridge is implemented
+- [ ] Review display of OpenClaw/plugin metadata once Monitor bridge is deployed
 
 ### 3.5 Future CLI alignment aids
 - [x] Consider showing canonical codes more prominently to help users map UI↔CLI
@@ -313,45 +316,49 @@
 - [x] Installer should copy `skills/hf/` when `--install-cli` is present
 
 ### 4.6 Monitor bridge endpoint
-- [ ] Define how plugin exposes OpenClaw metadata to Monitor over local port
-- [ ] Decide HTTP endpoint structure / payload schema
-- [ ] Expose OpenClaw version
-- [ ] Expose plugin version
-- [ ] Expose agent list / agent metadata
-- [ ] Ensure plugin remains functional even if Monitor never connects
+- [x] Define how plugin exposes OpenClaw metadata to Monitor over local port
+  - Plugin periodically POSTs metadata to Monitor bridge `POST /openclaw`
+- [x] Decide HTTP endpoint structure / payload schema
+  - `POST /openclaw` with `{ version, plugin_version, agents }`
+- [x] Expose OpenClaw version
+- [x] Expose plugin version
+- [x] Expose agent list / agent metadata
+- [x] Ensure plugin remains functional even if Monitor never connects
 
 ---
 
 ## 5. HarborForge.Monitor
 
 ### 5.1 Docker/runtime changes
-- [ ] Add `MONITOR_PORT` env var
-- [ ] Ensure Monitor listens on `127.0.0.1:<MONITOR_PORT>`
-- [ ] Update Docker runtime docs/examples
-- [ ] Update docker-compose to expose that port to host `127.0.0.1`
+- [x] Add `MONITOR_PORT` env var
+- [x] Ensure Monitor listens on `127.0.0.1:<MONITOR_PORT>`
+- [x] Update Docker runtime docs/examples
+- [x] Update docker-compose to expose that port to host `127.0.0.1`
 
 ### 5.2 Plugin communication
-- [ ] Implement local communication client to query plugin over `MONITOR_PORT`
-- [ ] Define request timeout / retry / fallback policy
-- [ ] Keep startup independent of plugin communication success
-- [ ] Keep heartbeat/telemetry upload independent of plugin communication success
-- [ ] If plugin is reachable, enrich telemetry with:
-  - [ ] OpenClaw version
-  - [ ] plugin version
-  - [ ] agent info
-- [ ] If plugin is unreachable, continue current behavior unchanged
+- [x] Implement local communication client to query plugin over `MONITOR_PORT`
+  - Note: the architecture is reversed — Monitor hosts the bridge, plugin pushes via POST /openclaw
+- [x] Define request timeout / retry / fallback policy
+  - Plugin uses 3s timeout; Monitor bridge uses 5s read/write timeouts
+- [x] Keep startup independent of plugin communication success
+- [x] Keep heartbeat/telemetry upload independent of plugin communication success
+- [x] If plugin is reachable, enrich telemetry with:
+  - [x] OpenClaw version
+  - [x] plugin version
+  - [x] agent info
+- [x] If plugin is unreachable, continue current behavior unchanged
 
 ### 5.3 Telemetry model alignment
-- [ ] Ensure backend-facing telemetry payloads can carry optional OpenClaw metadata
-- [ ] Avoid making plugin-derived fields mandatory
-- [ ] Ensure monitor data model cleanly distinguishes:
-  - [ ] host/hardware telemetry
-  - [ ] optional OpenClaw metadata
+- [x] Ensure backend-facing telemetry payloads can carry optional OpenClaw metadata
+- [x] Avoid making plugin-derived fields mandatory
+- [x] Ensure monitor data model cleanly distinguishes:
+  - [x] host/hardware telemetry
+  - [x] optional OpenClaw metadata
 
 ### 5.4 Docs / examples
-- [ ] Update Monitor README to explain `MONITOR_PORT`
-- [ ] Explain degraded mode when plugin bridge is absent
-- [ ] Provide example Docker run / compose snippet with host loopback exposure
+- [x] Update Monitor README to explain `MONITOR_PORT`
+- [x] Explain degraded mode when plugin bridge is absent
+- [x] Provide example Docker run / compose snippet with host loopback exposure
 
 ---
 
@@ -380,7 +387,7 @@
 ### Phase A — Foundations
 - [x] Finalize CLI help / mode / output model
 - [x] Finalize backend permission introspection approach
-- [ ] Finalize plugin↔monitor local protocol
+- [x] Finalize plugin↔monitor local protocol
 
 ### Phase B — Backend first
 - [x] Add/finish code-based backend support
@@ -403,7 +410,7 @@
 - [x] Remove plugin sidecar
 - [x] Add `--install-cli`
 - [x] Add `skills/hf`
-- [ ] Add `monitor_port` / `MONITOR_PORT` bridge
+- [x] Add `monitor_port` / `MONITOR_PORT` bridge
 
 ### Phase F — Cleanup / retirement
 - [x] Remove legacy backend Python CLI