Make Connect machine revocation retries idempotent

[ymichael]

Human comments

What was wrong

Connect machine cleanup could become permanently stuck after the remote revocation had already succeeded but its response was lost, or after local grant cleanup failed. On retry, the owned machine row was already revoked and no longer held a label claim, so revokeMachine returned not-found instead of acknowledging the completed revocation. The provider retained its local grant and every later retry failed the same way.

What changed

• Make revocation idempotent for an already-revoked machine owned by the authenticated account.
• Preserve existing authentication and account-ownership checks: missing devices, foreign devices, bogus credentials, and revoked server credentials still fail.
• Preserve label-claim tunnel closure and its retry behavior; a completed retry does not close the tunnel twice.
• No UI, public API shape, CLI, configuration, or server/daemon wire contract changed. No protocol-version bump is needed.

How you verified

• Added a regression that fails with the previous 404 behavior and passes when a completed owned revocation is retried through both dashboard and server-credential paths.
• pnpm exec turbo run test --filter=@bb/web --force -- src/server/api.test.ts: 31/31 passed.
• pnpm exec turbo run test --filter=bb-plugin-connect --force -- src/server-access.test.ts src/tunnel-lifecycle.test.ts: 20/20 passed.
• pnpm exec turbo run typecheck build --filter=@bb/web --force: passed.
• bb plugin build plugins/connect: passed.
• Targeted formatting and git diff --check passed.
• Independently exercised response-loss, real SQLite deletion-failure, pending reconciliation, authorization, and socket-cleanup recovery cases with owned local fixtures; no cloud credentials or vendor resources were used.

Follow-up to #3274.

AGENT GENERATED