Verify dependency removal

A change ships that was meant to remove a dependency: a credential is deleted, a server is unconfigured, an integration is torn out. The PR merges, CI is green, and the team moves on. Nobody rescans to confirm that what was supposed to disappear actually did, across every connected repository, not just the one that was edited.

“I removed it” and “it's actually gone” are different claims. A credential can still be referenced from a repository the author didn't touch. A reference can be ambiguous enough that nobody noticed it during the change. Verifying removal means re-examining dependency state after the change, not trusting that the diff did what it intended.

wirecheck verify retirement rescans and reports one of three states: confirmed removed, unresolved references remain, or known consumers remain. It never reports success by inference, only by checking the dependency graph after the change actually happened.

wirecheck verify retirement stripe-mcp --operation REMOVE --json

{ "status": "REMOVAL_VERIFIED", "targetRemoved": true, "knownConsumers": [], "unknownConsumers": [] }

{ "status": "UNRESOLVED_REMAIN", "targetRemoved": true, "knownConsumers": [], "unknownConsumers": [{ "name": "legacy-sync.sh" }] }

{ "status": "CONSUMERS_REMAIN", "targetRemoved": false, "knownConsumers": [{ "name": "billing-agent" }], "unknownConsumers": [] }

Only REMOVAL_VERIFIED means the removal is actually confirmed clean. The other two are specific, actionable states, not a generic failure.

Verification reflects the state of the most recent completed scan of the repositories involved, not the state of the pull request. If a known or unresolved consumer remains, it is named, not just counted.

Verification is only as current as the last scan; if a repository hasn't been rescanned since the change, Wirecheck reports that the data is stale rather than giving a false-confident answer. A reference it genuinely can't classify is reported as unresolved, not silently cleared.