Add packaged Insta360 X4 integration and recover paired Node channels

Discover independent camera instances and prepare their versioned runtime
from Node or remote Core. Add isolated SDK workers, camera controls, raw
dual-fisheye WebRTC preview, and shared action/region loading states.

Recover existing Node bindings over known Tailscale addresses after a Core
LAN address change. Preserve identities and trust, pin both peers, migrate
endpoints with revision checks, and require real heartbeats for online status.
Fix the Python client certificate profile for Go X509 verification.

Pin Design Guideline 8c53f73 and retain installer/build/acceptance history.
Node 0.8.19 is installed; X4 0.1.3-3 is bundled but hardware activation is pending.

Validation: qualified DG/Node builds and Go race tests; 31 fleet tests;
Python-to-Go certificate interoperability and live tailnet recovery with five
fresh heartbeats; prior 38 X4 tests and bounded remote WebRTC acceptance.
Clean-OS, replug/power autonomy, local X4 video and long-run stability remain open.

AGENTS.md

@@ -62,6 +62,40 @@ and the boundary between Mission Core and vendor-specific integration code.
 - Synthetic or explicitly redacted fixtures may be committed under
   `tests/fixtures/`.
 
+## Insta360 and clean-host installation — owner requirement, 2026-09-08
+
+- The current X4 starting point is USB enumeration only. SDK installation,
+  camera initialization and live video have not been accepted.
+- Every Ubuntu change needed for Insta360 must execute through the shipped
+  installer or the application's versioned device-preparation workflow from
+  the first board experiment. Do not repair the board with an ad-hoc apt/pip
+  install, copied library, chmod, environment override, service edit or root
+  invocation and promise to package it later. Fix the product artifact first,
+  then rerun that artifact. Read-only engineering inspection remains allowed.
+- Document every relevant action and its before/after evidence in
+  `docs/node/07_INSTA360_X4_INSTALLATION_LEDGER.md`; record the artifact version,
+  owning installer step, dependencies, idempotency, failure behavior and rollback.
+  Keep private logs/identifiers/media out of Git and redact their public summary.
+- A working prepared Mini is not clean-Ubuntu acceptance. Qualify dependency
+  closure on the declared clean OS image and actual USB operation separately;
+  installer, preparation and GUI acceptance must use the same shipped code.
+- X4 is operator live video and camera control (settings, photo, recording
+  start/stop and file access), per the owner’s subsequent scope expansion.
+  Preview and recording are separate operations. No stitching, AI, navigation
+  or vehicle-control integration is admitted. Model support and physical device instances are separate: several
+  cameras of the same model must retain independent identity and lifecycle.
+- Follow the scoped implementation plan in
+  `docs/node/06_INSTA360_X4_AND_MULTI_CAMERA_PLAN.md`. It is a proposed plan,
+  not evidence that SDK compatibility, hardware capacity or installation passed.
+- Subsequent owner direction: the existing Ubuntu Mini is the available build
+  and qualification machine; do not depend on Worker 006 or another host for
+  this X4 work. Its existing GCC may compile through a versioned build artifact
+  in bounded temporary staging. This is a build step, not runtime installation:
+  no system changes, SDK execution or camera access during compilation. The
+  final installer must carry the compiled payload so a clean operator Ubuntu
+  does not inherit an undeclared compiler/build-cache prerequisite. All board
+  staging/build/install/test actions remain documented and artifact-owned.
+
 ## Implementation order
 
 Follow the gates in `docs/01_IMPLEMENTATION_PLAN.md`. Do not build heavy