[ZhuchkaTriplesix]

Closes #1303

Problem: ConnectionSecretsStore.readForConnection / readSshSecretsForConnection caught every error and returned nulls, and the drivers wrapped the read in catch (_) {}.

1. A locked keyring or a missing secret service looked like a connection with no password: the user saw Authentication failed. Check the username and password and retyped a correct one.
2. updateConnection read the previous secrets the same way. With the read failing silently, the next write stored the missing password as empty (a delete), so an unrelated edit could erase it.

Fix

• New SecretsStoreUnavailableException. The reads throw it when the backend throws; an absent key still reads as null. A missing profile id (nothing stored yet) is still "no secrets".
• PostgreSQL, MySQL, MongoDB and Redis connect paths no longer swallow it: the connect fails with Could not read the saved credentials from the system keyring... Unlock the keyring or start the secret service. mapDatabaseError maps it before the text matching, so it is never an authentication failure.
• LocalDb.updateConnection reads the previous secrets before touching the row, so it stops without writing; the connections panel's edit flow shows the message in a toast instead of saving.
• List hydration (getConnections(hydrateSecrets: true)) keeps its tolerance: the row loads without its password and the connect reports the keyring.

Tests: store reads (throws on a failing backend, null for absent keys, SSH too); an edit with an unreadable store changes nothing and the saved password survives; each driver's connect surfaces the keyring error; the mapper keeps it apart from authentication failures. The old test that expected nulls on a failing read now expects the exception.