fix(keyring): reuse one Secret Service session per process

[gnacho]

Closes #221.

Every keyring operation (get/set/delete/search/unlock/adopt) opened a fresh D-Bus connection and negotiated a new DH session. The recurrent gnome-keyring crash investigated in #216 (Ubuntu bug 2161749) is a race in that session negotiation that any client can trigger, so each new session is another chance to hit it.

This keeps one process-wide session, created lazily on first use:

• All operations in credentials.rs share it, serializing access through a Mutex (engine threads and UI).
• On a retryable failure (transport error, crypto/session mismatch, daemon restarted) the cached session is dropped and the operation reconnects exactly once. No loops.
• Domain errors (Locked, NoResult, Prompt, non-UTF-8 secret) never reconnect: a new session cannot change them, and Locked must keep surfacing as-is for the Locked keyring is misreported as AuthRequired (Account Needs Attention) #98/Recover from a locked keyring without restarting the app #214 flows.
• The cache/reconnect policy is a pure helper with an injectable factory, covered by 6 hermetic tests (reuse, reconnect-once, no loop, domain errors, connect failure, test reset) that need no Secret Service. The existing real-keyring tests are untouched.

The session is leaked by design (the process is long-lived and the crate ties collections/items to &'a self of the service, so a process-wide instance must be 'static anyway); a reconnect leaks one more instance, which is negligible.

735->737 tests passing plus the usual known-flaky real-keyring pair, clippy -D warnings clean, fmt clean. No user-visible strings, no i18n changes.