[Bug]: Saved SSH environments can reappear or lose rollback state during removal

[mwolson]

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/desktop

Steps to reproduce

1. Add a desktop-managed SSH saved environment.
2. Delete it from Settings while SSH disconnect cleanup is slow or still running.
3. Restart T3 Code.
4. In a separate flow, re-add the same SSH target when it reports a new environment id, then have credential persistence fail.

Expected behavior

Deleting a saved SSH environment should remove its persisted metadata and embedded credential in one operation before background SSH cleanup can rewrite stale state.

If re-pairing the same SSH target fails to persist the new credential, rollback should restore the previous saved record and preserve the original credential-persistence error.

Actual behavior

Removal used separate registry and secret writes around SSH cleanup. The cleanup path could race with metadata removal and leave stale saved-environment state behind.

Replacement rollback also snapshotted only the new environment id, so a stale SSH record could be lost when credential persistence failed. A rollback failure could hide the original credential persistence failure.

Impact

Major degradation or frequent failure

Version or commit

main before the saved-environment persistence fix

Environment

Desktop app with saved SSH environments. Observed while testing Linux AppImage remote environment pairing, but the persistence ordering issue is in the saved-environment flow.

Logs or stack traces

No stack trace required. The issue is persistence ordering and rollback behavior around saved SSH environment removal and replacement.

Workaround

Manually remove the stale saved-environment persistence entry, then restart T3 Code.