registration: self-assigned camera IDs (Option B) + tolerate clockless status

Auto-registration never completed: the firmware announced on the wrong
topic, the hub never replied, and an unregistered node couldn't receive a
reply anyway. Switch to self-assigned IDs:

firmware (esp32-mqtt-bridge.cpp):
- camera_id defaults to the device id (clientID, e.g. rig-86d978)
- always subscribe to <id>/command; announce on the contract topic
  remoterig/cameras/<id>/announce (was the unmatched announce-<id> form)
- drop the bogus numeric timestamp from status (node has no clock)

hub (subscriber.go):
- handleAnnounce registers new cameras under the node's self-assigned id
  (no cam-NNN, no registered reply)
- handleStatus tolerates an empty/invalid timestamp and stamps server-side
  (previously rejected the status outright)

docs/MQTT_CONTRACT.md updated to match.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

docs/MQTT_CONTRACT.md

@@ -176,11 +176,19 @@ Published once on ESP32 first boot (or factory reset). Used for auto-registratio
 | `capabilities` | string[] | Supported features |
 | `friendly_name` | string | Default human-readable name |
 
-**Hub behavior on first announce:**
+**Camera IDs (self-assigned — "Option B"):** the node uses a stable
+device-derived id (`rig-<last3 MAC bytes>`, e.g. `rig-86d978`) as its
+`camera_id` from first boot, and uses it for all topics
+(`announce`/`status`/`heartbeat`/`command`). There is no hub-assigned
+`cam-NNN` and no `registered` reply handshake.
+
+**Hub behavior on announce:**
 1. Check if MAC already registered → if yes, update `friendly_name` and log
-2. If new MAC → create camera with auto-generated `camera_id = "cam-<NNN>"` (zero-padded sequential)
-3. Respond by publishing: `remoterig/cameras/<camera_id>/command` with `command: "registered"` payload containing the assigned `camera_id`
-4. Broadcast via SSE that a new camera appeared
+2. If new MAC → insert the camera using the node's self-assigned `camera_id`
+3. Broadcast via SSE that a new camera appeared
+
+> Note: nodes have no real-time clock, so `timestamp` may be absent; the hub
+> stamps received-time server-side.
 
 ### Topic: `remoterig/hub/status`