P0: preflight deployed runtime targets before shared dependency rollout

[Pigbibi]

Problem

A shared-runtime dependency rollout can be source-compatible while an older deployed service still references a strategy profile that is no longer admitted by the canonical catalog. The container then fails closed at startup.

Required guard

• Before an image rollout, resolve every targeted Cloud Run runtime target against the pinned catalog and adapter capability matrix.
• Require STRATEGY_PROFILE and runtime-target profile to agree, and require the target mode/dry-run flags to meet the declared deployment policy.
• Fail the deployment before traffic shifts if any target is retired, unsupported, or has a name/mode mismatch.
• Do not silently remap a retired strategy to another strategy; it needs a separate release/admission decision.
• Keep the verification generic for every strategy, plugin mount, and platform target.

Acceptance evidence

• Unit coverage for a retired profile and for profile/mode mismatch.
• Deploy workflow preflight executes before image build/traffic shift.
• A current-target audit report contains only non-sensitive identity/status fields.

[Pigbibi]

Audit evidence: the readonly Gateway capability is merged in #405. A scoped shadow rollout was prevented from continuing because the deployed legacy profile is not admitted by the current canonical catalog; the target was disabled and its shadow schedulers paused. This confirms the guard must be a pre-traffic deployment check, not a silent compatibility fallback.

[Pigbibi]

Implemented and merged in #407. Standard image rollouts now verify the deployed target against the pinned catalog before traffic shifts, and deployment cleanup is opt-in so rollback artifacts remain available.