feat(cli): deployment-filtered status renders the data-plane apply id as APPLY ID

[aparajon]

Why this matters

An operator running a deployment-filtered status scan is asking the data plane's question: what is the control plane driving on my deployment? The handle they correlate with the data plane's own storage and logs is the data-plane apply id — but the list rendered only the control-plane identifier, forcing a detour through detail views (or the data plane's tables) to find it.

What it does

• In --deployment mode the APPLY ID column renders the deployment's data-plane apply id when one is recorded — the id the read model now surfaces for both single-operation and folded per-shard rows.
• Rows without a recorded data-plane id (not yet dispatched, locally driven, or omitted after divergence) fall back to the control-plane apply id, so every row keeps a usable handle.
• The EXTERNAL OP ID column is unchanged (per-operation remote row id), and nothing changes outside deployment mode.

How it moves us toward the northstar

One data-plane apply per deployment; operations dispatch into it.

0  per-shard reconcile                          ✅ shipped
pre vschema-only deployment-scoped shape        ✅ shipped
pre op-lease drives settle projection-safely    ✅ shipped
1  dispatch granularity
   ├─ data-plane sibling attach                 ✅ merged
   └─ deployment-keyed idempotency + echo       ✅ merged
2  correlation persistence                      🔍 in review
3  op-scoped data-plane drive (shared apply)    verified in step 6
4  read model exposes the deployment apply id   🔍 in review
5  CLI renders it as APPLY ID in deployment mode ⬅ this PR
6  test matrix

Opened by Claude (Fable 5).