Part of epic #2179 (PR2 of 5). Depends on #2180 (scaffold + capabilities.py).

Scope

examples/fleet/02_cross_zone_transport.py: two zone orchestrator agents plus one fleet agent, each an in-process mesh peer (init_mesh(..., peer_id="zone-...") - the in-process multi-peer pattern from notebooks/06_fleet_orchestration.ipynb). One shared transport skill definition is executed in both zones by different robot types. The fleet agent decomposes a cross-zone request into a handoff dispatched via mesh.send behind the robot_mesh HITL gate.

Plus dashboard v1 - examples/fleet/dashboard.py: a READ-ONLY mesh peer subscribing presence/health/safety topics and tailing the signed audit log, rendered in Rerun (already a transitive dependency via lerobot; require_optional-gated with a clean install hint):

• fleet table: peer id, zone, presence age, current task, safety state
• event timeline: dispatch / estop / resume / HITL decisions

It attaches to the mesh, not the simulator, so the same dashboard serves every example in the suite and any backend (epic D9). A write-capable UI is an explicit epic non-goal.

Acceptance

• Suite criteria (CPU-only, seeded, air-gapped, smoke test)
• The same skill artifact executes in both zones with zero per-zone forks of skill code
• Dashboard runs as a separate process/peer, degrades gracefully when rerun is absent, and cannot publish commands (subscribe-only surface)

Board routing: please add to Strands Labs - Robots with Status=Todo, Priority=Medium (filing account lacks org project write).