[autodev] Step 13 partial: c10/c11/c12/c13 cycle-1 doc sync

Batch 4 of the cycle-1 component-doc sync. For each of C10
(provisioning), C11 (tilemanager), C12 (operator_orchestrator),
and C13 (fdr):

- Append "Cycle-1 operational reality" paragraph to § 1
  documenting the actual cycle-1 wiring path:
  - C10: operator-side / cross-tier; NOT in _STRATEGY_REGISTRY;
    composed via runtime_root/c10_factory.py with six per-service
    factories; reuses C7 InferenceRuntime for engine compile;
    AZ-323 Ed25519 signer + C10ManifestConfig signing-mode gate;
    AZ-324 ManifestVerifierImpl with airborne/operator modes;
    AZ-507 c6 cuts kept in c10_factory; AZ-687 N/A.
  - C11: operator-workstation-only; airborne build target
    excludes source tree (ADR-004 / AC-8.4); composed via
    runtime_root/c11_factory.py with three per-service factories;
    distinct FdrClient producer_ids for signing_key + tile_uploader;
    AZ-320 IdempotentRetryTileUploader wraps by default;
    AZ-507 keeps c6 surfaces caller-injected; AZ-687 N/A.
  - C12: operator-workstation CLI binary; airborne build excludes
    source tree (ADR-004 + Principle #9); composed via
    runtime_root/c12_factory.py; OperatorOrchestratorServices
    dataclass aggregates AZ-326/327/328/329/330/489 services with
    sibling fields defaulting to None; AZ-507 cuts via
    RemoteCacheProvisionerInvoker + TileDownloaderCut/UploaderCut;
    AZ-687 N/A.
  - C13: airborne infrastructure; pre_constructed[c13_fdr] seeded
    FIRST via make_fdr_client(AIRBORNE_MAIN_PRODUCER_ID, config)
    (AZ-619 Phase A); per-producer _CACHE gives AC-619.2 singleton;
    AZ-274 drop-oldest overrun policy wired at construction;
    c1_vio / c5_state require it, c2_5/c3/c3_5/c4 optional; AZ-687
    guard explicitly does NOT apply — seed runs before any block
    presence check so replay binaries still write FDR.

Also bump _docs/_process_leftovers/2026-05-11_d_cross_cve_1_opencv_pin_deferred.md
replay timestamp to 17:18 (start of this /autodev invocation);
gtsam==4.2.1 still requires numpy<2.0.0 so the relaxed opencv pin
remains in effect.

Update _docs/_autodev_state.md sub_step.detail to record batch
4/~5 done; next batch is the 8 helpers under common-helpers/.

Co-authored-by: Cursor <cursoragent@cursor.com>

_docs/02_document/components/12_c11_tilemanager/description.md

@@ -11,6 +11,8 @@ C11 is a **separate operator-side binary / image**. The airborne companion image
 
 **Architectural Pattern**: Pipeline behind two interfaces (`TileDownloader`, `TileUploader`) under one component, consistent with C8's multi-interface shape (FC-AP, FC-iNav, GCS adapters under one component). The two interfaces are bundled into C11 because they share auth (TLS + service-internal API key for download, per-flight onboard signing key for upload), HTTP client, network configuration, deployment unit (operator-tooling tarball), and the airborne-exclusion property — splitting them into two components would duplicate all of that. They are kept as **two interfaces** so SRP is preserved at the call-site level: C12 binds `TileDownloader` for the F1 cache-build workflow, `TileUploader` for the F10 post-landing trigger; neither is forced to depend on the other.
 
+**Cycle-1 operational reality**: C11 is **operator-workstation-only**, NOT an airborne strategy slot — there is no `c11_tile_manager` slot in `_AIRBORNE_REGISTRATIONS`, no row in `AIRBORNE_REQUIRED_PRE_CONSTRUCTED_KEYS`, and the airborne companion image's build target deliberately excludes the entire `c11_tile_manager/` source tree (ADR-004 process-level isolation; AC-8.4). The operator binary composes C11 via `runtime_root/c11_factory.py`, which exposes three tiny per-service factories — `build_per_flight_key_manager` (AZ-318), `build_tile_uploader` (AZ-319 + AZ-320), and `build_tile_downloader` (AZ-316) — each called explicitly by C12's CLI; no central registry. FDR wiring goes through the per-producer `make_fdr_client` cache: AZ-318 `PerFlightKeyManager` defaults to `make_fdr_client("c11_tile_manager.signing_key", config)`, AZ-319 `HttpTileUploader` to `make_fdr_client("c11_tile_manager.tile_uploader", config)` — both distinct from the airborne `"airborne_main"` producer, so the operator-workstation process gets its own per-component FdrClient instances rather than sharing the airborne singleton. AZ-320's `IdempotentRetryTileUploader` decorator wraps `HttpTileUploader` by default (per-call + per-tile bounded retry); `config.components['c11_tile_manager'].disable_retry_decorator = True` suppresses the wrap for low-level debugging or test wiring that needs to observe the inner uploader. The AZ-507 cross-component cut keeps C11 from importing C6 directly: `tile_store` / `tile_metadata_store` are passed in by the operator-binary composition root as consumer-side cuts; `http_client` (an `httpx.Client`) is also caller-owned so tests can swap in `httpx.MockTransport`. AZ-687 replay-mode guard does not apply — C11 has no airborne footprint.
+
 **Upstream dependencies**:
 
 - C12 OperatorTooling → invokes `TileDownloader.download_tiles_for_area(...)` during F1 and `TileUploader.upload_pending_tiles(...)` post-landing.