fix(mobile): allow stale environments to be deregistered

[Rowan-Paul]

Problem

Mobile shows stale or unhealthy T3 Connect environments, but unconnected rows only expose a connect switch. Users cannot deregister an environment when its managed endpoint is unavailable.

Fix

• add a destructive deregistration action beside unconnected T3 Connect environments
• confirm before revoking account access and removing the managed tunnel
• refresh relay discovery after successful deregistration
• report a clear error if the T3 Connect session disappears
• update the mobile user documentation

Before

The unavailable environment only has a disabled connection switch.

After

Unavailable T3 Connect environments have a destructive deregister action beside the connection switch.

Verification

• vp test run packages/client-runtime/src/relay/managedRelayState.test.ts apps/mobile/src/features/connection/environmentSections.test.ts
• vp run --filter @t3tools/mobile typecheck
• targeted lint for the changed mobile files
• iPhone 17 Pro simulator: verified the trash action and confirmation dialog with safe showcase fixtures

Generated by GPT-5.6-sol using the T3 Code Codex harness.

---

Note

Medium Risk
Deregistration revokes account-level T3 Connect access and is irreversible from the UI; the discovery refresh concurrency change affects all clients using that command but is covered by a new test.

Overview
Lets mobile users deregister unconnected T3 Connect environments (e.g. stale or unreachable) without relying on a working connect path.

Mobile: Adds deregisterManagedRelayEnvironmentCommand (serial per account) and wires it into the T3 Connect environment rows—a confirmation dialog, destructive trash control beside the connect switch, per-row loading/disable state, relay list refresh on success, and alerts when the session is missing or the API fails.

Client runtime: Changes relay environment discovery refresh from singleFlight to latest so a refresh kicked off after deregistration (or other mutations) always runs a new pass instead of reusing an in-flight refresh that started before the mutation; adds a test for that behavior.

Docs: Updates mobile deregistration steps to Settings → Environments and the deregister control beside the environment.

^{Reviewed by Cursor Bugbot for commit b78cf0d. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Add deregisterManagedRelayEnvironmentCommand for stale mobile relay environments

Adds a module-level atom command scheduler in managedRelayState.ts that delegates environment deregistration to the managed relay service. Requests are serialized by account ID and accept an account ID plus environment ID, so deregistration requests for the same account process one at a time.

^{Macroscope summarized b78cf0d.}

[macroscopeapp]

🟡 Medium connection/CloudEnvironmentRows.tsx:150

After a successful deregistration, the removed environment can remain displayed because controller.refreshRelayEnvironments() may only await an in-flight refresh that started before unlinkEnvironment completed. Ensure the post-delete path schedules a new discovery refresh after that operation finishes, rather than relying on the singleFlight call to start one.

🤖 Copy this AI Prompt to have your agent fix this:

In file @apps/mobile/src/features/connection/CloudEnvironmentRows.tsx around line 150:

After a successful deregistration, the removed environment can remain displayed because `controller.refreshRelayEnvironments()` may only await an in-flight refresh that started before `unlinkEnvironment` completed. Ensure the post-delete path schedules a new discovery refresh after that operation finishes, rather than relying on the `singleFlight` call to start one.

[cursor]

Cursor Bugbot has reviewed your changes using default effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

Want higher recall? High effort reviews run extra passes and find more bugs. A team admin can switch effort levels in the Cursor dashboard.

^{Reviewed by Cursor Bugbot for commit c987072. Configure here.}

[macroscopeapp]

Approvability

Verdict: Not approved

Macroscope's review found this PR not approvable — The PR adds a destructive mobile deregistration workflow that revokes T3 Connect access and removes managed tunnels, while also changing shared refresh concurrency used by mobile and web. An unresolved Medium-severity stale-list concern remains around the post-deregistration refresh path.

Not approved because:

• 1 blocking correctness issue found at or above your repo's Minimum Blocking Severity

^{Adjust the Minimum Blocking Severity for this repo — including turning it Off — in Settings. You can add or adjust custom eligibility rules. Learn more.}