fix: avoid rewriting all passwords when editing one connection

[agouil]

Context

Connection details are stored in a single connections.json index, while passwords (database and SSH) are stored securely in the OS keyring — macOS Keychain, Windows Credential Locker, or Linux Secret Service.

Until now, saving a change to one connection rewrote the keyring entries for every saved connection, not just the one being edited. Adding, updating, and deleting a connection all funneled through a "save everything" path that looped over the full list and re-wrote each connection's stored password.

Why this was necessary

On many systems a keyring write is not free: it can be slow and, in some configurations, prompt the user for access each time. As a user's list of saved connections grows, editing a single connection became progressively slower and could surface repeated keyring access prompts — a poor experience for what should be a trivial change.

What changed

• Persisting a connection now writes only that connection's credentials to the keyring.
• Renaming a connection now also cleans up the stale keyring entries stored under the old name.
• The shared connection index file is still written in full (all connections live in one file), but that write no longer touches the keyring for unrelated connections.
• Add, update, delete, and both save flows in the UI now use the per-connection path.

Impact

• Editing a connection is faster and no longer triggers keyring activity for unrelated connections.
• Fewer keyring access prompts on systems that gate each write.
• No behavior change across operating systems: all credential access still goes through the same cross-platform keyring layer, and existing passwords are preserved (a save with no new password re-reads the stored value rather than clearing it).

Testing

• New test suite covering the per-connection save path: only the edited connection's credentials are touched, rename moves credentials and removes the old ones, and add/update/delete/empty-password/error paths behave correctly.
• Full test suite passes (one unrelated, pre-existing failure in install-strategy detection on Python 3.14).
• Snyk SAST scan of the connections domain surfaced no issues introduced by this change.

[Maxteabag]

Thanks for the PR — it's a nice improvement. I’m merging this now.

I found one rename-ordering edge case around omitted credentials and failed keyring rename; I’ll handle that now in another pr so your core optimization can land without asking you for another revision.