Revoke Tailcat access through existing pairing removal #881

Parent

#868

What to build

Removing Cloud access immediately stops ordinary Cloud use and truthfully distinguishes confirmed endpoint revocation from an offline, unconfirmed removal. This extends pairing/removal rather than adding a controller.

Acceptance criteria

• Disable new Cloud connections immediately and cancel active Cloud sessions using existing lifecycle cancellation. Preserve only the protected attempt metadata necessary to attempt/report endpoint revocation; do not delete the last usable credential first.
• On confirmed removal the endpoint atomically persists a replacement/disabled capability and closes sessions using the old one. Old capability dials fail immediately and after restart; re-enrollment does not revive old access.
• Offline endpoints report pending/unconfirmed through existing teardown outcomes. Database deletion alone cannot be reported as remote revocation; no periodic controller or public helper-control service.
• Keep independently authorized SSH access working. Explain shared-capability administrative access: no per-user Tailcat revocation, and Cloud logout does not invalidate separately held direct capabilities.
• Rung 2 — immediate Cloud disable/cancellation, retained removal attempt, offline outcome and re-enrollment. Rung 1/4 as needed — active stream closure and old-capability rejection across actual endpoint restart. Supersede centrally enforced Relay Revoke semantics in the existing architectural documentation.

Blocked by

• Enroll a Founding Machine and open it from Cloud through Tailcat #879