docs: put MinIO first-class on ground, add executive overview

Treat MinIO as existing stack infrastructure (default T3 warehouse, not
on the drone), add a one-page executive map, and record placement as an
open team question rather than a rip-and-replace.

docs/02-architecture.md

@@ -21,11 +21,12 @@ graph TB
             HOOK["event hook<br/>fires on new derived data"]
             PUB["state publisher<br/>pub/sub broadcast"]
             BULK["bulk sync<br/>rsync over SSH"]
-            MINIO["MinIO<br/>optional derived bucket"]
             QAPI["query API<br/>SQL-over-SSH"]
         end
     end
 
+    MINIO[("MinIO — ground warehouse T3<br/>already in the stack")]
+
     SENSORS --> WRITER
     VIDEO -->|detections| WRITER
     WRITER --> NVME
@@ -33,15 +34,16 @@ graph TB
     DUCK --> NVME
     WRITER -->|derived rows| HOOK
     HOOK --> PUB
-    HOOK --> MINIO
     HOOK --> BULK
     QAPI --> DUCK
     PUB -.->|mesh pose| PEERS["peer drones"]
     BULK -.->|sealed partitions| PEERS
     QAPI -.->|on demand| PEERS
+    NVME -->|post-flight offload| MINIO
 ```
 
-MinIO stays available where an S3 API helps (on-board derived datasets, ground warehouse). **In-flight peer bulk sync is SSH/rsync**, not object-store replication — see [04 — Swarm sync](04-swarm-sync.md).
+**MinIO** is already in the stack and is the **default ground warehouse (T3)** behind offload — keep it, do not rip it out. Default sketch: **not on the drone** (CPU/RAM budget); on-board MinIO remains an allowed exception if Compose already depends on an S3 API. **In-flight peer bulk sync is SSH/rsync** (or team-standard MinIO replication if that is already how ops works) — never the 5 Hz pose path. See [00 — Executive](00-executive.md) and [04 — Swarm sync](04-swarm-sync.md).
+
 ### Layer 1 — Ingestion
 
 - `sensor-ingest` subscribes to sensor sources (ROS 2 topics where available, raw drivers otherwise) and normalizes them into typed streams: IMU, barometer, temperature, LiDAR, RSSI, power, and so on.
@@ -56,10 +58,11 @@ MinIO stays available where an S3 API helps (on-board derived datasets, ground w
 
 ### Layer 3 — Serving and sync
 
-- The **event hook** is the on-board "lambda": when the writer lands new *derived* rows (state, detections), it triggers registered actions — broadcast, optional MinIO put, bulk-sync hint, or a local mission-logic callback. Nothing polls.
+- The **event hook** is the on-board "lambda": when the writer lands new *derived* rows (state, detections), it triggers registered actions — broadcast, bulk-sync hint, or a local mission-logic callback. Nothing polls.
 - The **state publisher** broadcasts compact position/attitude/detection payloads over the mesh pub/sub (UDP in the PoC; Zenoh proposed — [04](04-swarm-sync.md)).
-- **Bulk sync** pulls sealed derived partitions from peers over persistent SSH (rsync delta transfer). MinIO is optional where an S3 API is wanted; it is **not** the in-flight peer replication path.
+- **Bulk sync** pulls sealed derived partitions from peers over persistent SSH (rsync delta transfer). If the team already operates MinIO replication for that job, reuse it — do not invent a second path. Pose traffic never goes through MinIO.
 - **Peer queries** are read-only DuckDB SQL — HTTP explorer gate in the PoC; **SSH forced commands** proposed for flight (SELECT-only gate, read-only OS user, columnar responses — [04](04-swarm-sync.md)).
+- **MinIO** sits on the **ground** as T3 by default ([00 — Executive](00-executive.md)); on-board MinIO is an explicit exception, not the baseline.
 
 ## Communication planes