feat(cli): spi load — named loads with published state

Part of the **Borrow, Prove, Restore** design (§6 Tier 2, D11, D12). Phase 3.

Adopt the cimpl-stack load concept with four deliberate changes:
- **Registry as data**: datasets declared in YAML (name, source repo/ref, archive path, type, `requires`), not CLI code.
- **Runs at rebuild time**: the lifecycle pipeline's final stage executes the registry's default set; "ready" and "seeded" stay separate signals.
- **Labeled Jobs as the state contract**: `role=data-load` + `dataset=`; `skipdupes=true`, 409-as-success, ≤1% failure threshold; four-state re-run behavior (Complete no-op / Running no-op / Failed recreate / --force recreate).
- **Durable published state**: a marker ConfigMap surfaced as a `loads` block in `spi info --json` (Jobs TTL away; facts must not), so fork CI gates can enforce descriptor `requires.loads` with a typed refusal.

Fast-follow (may split out, must not slip past Phase 3): mirror archives to Azure storage with digests; pin refs beside the chart pins.

## Acceptance
- `spi load --dataset reference-data` seeds an environment; re-run is a no-op; `spi info --json` reports the load durably after Job TTL expiry.

Start by tracing the existing lifecycle pipeline and the CLI entry points for `spi load` and `spi info --json`, then map the registry, labeled Jobs, and durable ConfigMap state described in the Phase 3 design. Done means `reference-data` seeds an environment, reruns are no-ops, and the reported load remains available after Job TTL expiry; also confirm whether the Azure archive and chart-ref fast-follow belongs in this issue.

Written by the indexing model from the issue text.