[ZhuchkaTriplesix]

What

MemorySecretsStorageBackend (tests only) could fail only the next call. It now also:

• counts calls per kind (read / write / delete), failed ones included, numbered from 1; clear() and resetCounts() restart the numbering;
• failOnCall(op, n, error) fails the Nth call once, failAlways(op, error) fails every call until heal(op);
• a failing call throws before the stored values change; the failNext* flags keep working and win over the other faults;
• keys shows what is stored, to check that no secret is left behind.

Nothing is added to the production backend; default behaviour is unchanged.

Tests

• memory_secrets_backend_test.dart: the guarantees above.
• secrets_failure_test.dart: what the app does when the keyring refuses a request part-way. addConnection fails on the 2nd write and on an SSH key write (no row, no secret left, original error rethrown, also when the cleanup is refused); updateConnection restores the old row and both old secrets after the new password was stored; a read that fails on the 2nd key is SecretsStoreUnavailableException, not "no password"; the list loads without the password while the keyring is down; retries after a refusal.
• save_new_connection_test.dart: a save that fails on the 2nd secret leaves nothing and the same row saves on retry.

Checked by removing deleteForConnection from the rollback in addConnection: three of the new tests fail.

Only tests were run (the files above plus local_db_secrets_test and secrets_unavailable_connect_test), and dart analyze; no live check of a locked keyring.

Not covered

The contract is not written down for: the restore failing too in updateConnection (#1778), and TeamProfileCodec.importInto stopping at the first failed save (#1759).