extension_migration_pending holds pm health at ok false but no command applies a pending extension migration #909

Summary

pm health reports extension_migration_pending and counts it in
triage.migration_pending_count, but no command in the CLI applies a pending extension
migration. The warning is permanent, it holds pm health at ok: false, and there is no
documented or discoverable way for an agent or a human to clear it.

Reproduction — pm-cli 2026.8.5

Install any extension that ships a registerMigration (both published starter packages do), then:

$ pm health --json | jq '.checks[]|select(.name=="extensions").details.triage
                        |{warning_count,migration_pending_count,migration_failed_count}'
{
  "warning_count": 12,
  "migration_pending_count": 2,
  "migration_failed_count": 0
}

Warnings:

extension_migration_pending:project:pm-starter:pm-starter-0001-noop
extension_migration_pending:project:pm-ts-starter:ts-starter-noop

The count does not change after running write commands (pm create, etc.) in the workspace —
verified across several mutations.

There is no remediation surface

Everything reachable is diagnostic-only:

PreflightRuntimeDecision exposes run_extension_migrations / enforce_mandatory_migration_gate,
but those are override inputs, not a user-invocable action, and the published overrides here are
conservative pass-throughs that preserve the host decision (ctx.decision?.run_extension_migrations ?? true),
so nothing is suppressing the run from the extension side.

Impact

• pm health ok: true is the fleet's CI/release gate. A permanently-pending migration means a
  workspace can never pass it, for a reason the operator cannot act on.
• It is indistinguishable, from the outside, between "the host has not run these yet" and "these
  are broken" — migration_failed_count stays 0, so there is no signal either way.
• This is the same shape as graph audit stale_lifecycle_block has no honest resolution for work blocked on an external party, despite blocked_reason carrying the evidence #891: a diagnostic that reports a state with no honest resolution.
  The only ways to make it quiet are to stop shipping migrations or to ignore the check, and both
  discard real signal.

What would close it

Any one of:

1. A user-invocable apply path — pm extension migrate (or pm extension --migrate, or a
   --apply-migrations flag on pm health/pm package) that runs pending extension migrations
   and reports applied/failed counts.
2. If migrations are meant to apply automatically, document when, and make the warning state
   why this one has not run yet (gate disabled? scope mismatch? not yet triggered?).
3. Failing both, add a remediation_map entry for extension_migration_pending naming the exact
   command, exactly as the telemetry check already does for telemetry_queue_pending.

Option 3 alone would at least make it actionable; option 1 is what the warning implies exists.

Environment

• @unbrained/pm-cli 2026.8.5
• Node 22, Linux
• Project-scope extensions, 17 published pm-* packages installed