feat: graceful sub-CA decommissioning — migration transparency + client renewal signal

[Bugs5382]

Idea (Shane, 2026-07-06): make retiring a sub-CA a visible, self-service migration instead of a scramble.

Two halves

1. Migration transparency (FM-side). When a sub-CA is flagged pending decommission, the Fleet Manager surfaces the non-secret list of certs it issued that are still valid — i.e. which systems must move to the successor CA before decommission. Built on the issued-cert inventory (ListIssued): a 'decommission plan' on that node showing remaining live certs, their subjects, and expiries, and migration progress as systems re-enroll elsewhere.

2. Proactive client signal (node-side). Mark issued certs (or advertise via the node API / OCSP / a well-known metadata endpoint) so a system holding a cert can self-discover: 'my issuing CA is being decommissioned / will expire — request a new cert from <successor node/endpoint>.' Candidate mechanisms: an X.509 extension or AIA-style 'renewal authority' pointer to the successor's enrollment endpoint; a decommission/renew-from hint the node advertises; enrollment clients (ACME/EST) checking it and auto-re-enrolling.

Ties to

• Issued-cert inventory + revocation (shipped).
• CA lifecycle: subordinate re-key (shipped) and root cross-signed rollover (feat: root CA key cross-signed rollover (post-v1.0.0) #161).
• Enrollment adapters (held until the web/Fleet Manager exists) — ACME/EST are the natural 'ask for a cert from this node' channel (feat(enroll): native Windows autoenrollment via GPO (MS-XCEP/WSTEP), no third-party agent #108/feat(enroll): ACME HTTP-01/DNS-01 so cert-manager and native ACME clients enroll without an agent #110).
• Fleet Manager UI (in progress): the decommission plan is a natural FM view.

Backlog — not scheduled; surfaced during FM fleet-visibility co-design.