fix(storage): a failed updateConnection can leave the row and the keyring out of step, and nothing says so #1778

Problem

ConnectionRepository.updateConnection writes the new row to SQLite, then the secrets one key after another. When a secret write fails it restores the old row and then writes the old secrets back, "best effort": a failure of that restore is swallowed (catch (_) {}) and only the original error is rethrown.

If the keyring refuses the restore as well (a keyring that went away mid-save, which is the failure mode this code exists for), the stored state is half old, half new: SQLite has the old row, the keyring may hold the new password (written before the refusal). The user sees "not saved", the connection still shows the old host, and connecting uses the new password. Nothing is logged.

Found while writing the regression tests for failing secrets (test/core/storage/secrets_failure_test.dart); that file covers the case where the restore works. The behaviour when the restore fails too is not covered because the intended contract is not written down.

Proposal

Decide the contract, then test it. Options:

• keep best effort, but log the failed restore (debugPrint/logIgnored with the connection id) so the state can be explained;
• or write the secrets first and the row after, so a refusal leaves the old row and the old secrets untouched.

Where

• lib/core/storage/connection_repository.dart (updateConnection, the restore in the catch)