fix: support desktop-selected Secret Service providers

[UglyEgg]

Problem

The package requires GNOME Keyring even though its runtime interface is the Freedesktop Secret Service API. That prevents desktop-selected providers from being treated as first-class implementations.

The current availability check also performs a real keyring operation. This can require a usable default collection, create one as a side effect, or prompt before the client actually needs a secret. Python Keyring opens a fresh Secret Service connection for each operation, so providers that authorize clients by D-Bus identity may prompt repeatedly.

Change

• Make GNOME Keyring a packaging suggestion rather than a hard Debian or RPM dependency.
• Validate Secret Service availability without reading or creating a secret.
• Prefer the Freedesktop default alias; if it is missing or stale, use the sole advertised collection, create a default only when no collection exists, and reject ambiguous multi-collection fallback.
• Reuse one serialized D-Bus connection for the backend lifetime so provider authorization can persist across operations. The backend does not cache plaintext and closes the connection explicitly or through a finalizer.

GNOME Keyring, KeePassXC, KWallet, and other conforming Secret Service implementations use the same code path. No provider-specific logic or secret-storage schema change is introduced.

Verification

• 10 focused tests cover non-invasive validation, default/sole/empty/ambiguous collection selection, connection reuse, explicit close/reopen, credential reads, writes, and deletion.
• Complete upstream suite: 31 passed.
• ruff check, Python bytecode compilation, and git diff --check pass.
• The equivalent downstream overlay has been exercised on Fedora 44 Plasma with KeePassXC as org.freedesktop.secrets, including cold start, login, sign-out/sign-in, reconnect, and one authorization prompt per client start.

Closes #3.

Development disclosure: I developed this patch with material assistance from OpenAI Codex under my direction, then reviewed, tested, and signed the final change.

[luke-titley-proton]

Will have to look into this more deeply, but we're hoping to move some of this logic into our rust layer at some point in the coming months, this is potentially going to have to be re-written.

My cursory understand is:

• You've got cascading collection lookup (default, if not first, if not create)
• You're persisting the dbus connection for app lifetime
• You've made gnome-keyring a suggestion

[UglyEgg]

Thanks! Yes, that is essentially the intent, with one small clarification on collection selection.

The fallback is:

• use the default alias when available;
• if the alias is absent and exactly one collection is advertised, use that collection;
• if no collections exist, create a default collection;
• if multiple collections exist without a default alias, fail rather than selecting one arbitrarily.

The D-Bus connection is opened lazily and retained for the lifetime of the keyring backend instance, then explicitly closed or closed by its finalizer. It does not cache plaintext secrets. The purpose is to keep a stable Secret Service client identity across operations so the provider can retain its authorization decision rather than treating each operation as a new client.

And yes, GNOME Keyring becomes a suggested provider rather than a required implementation. The runtime path remains the standard Freedesktop Secret Service interface.

The useful part of this PR may ultimately be the behavior and regression cases rather than the Python implementation itself. I would be happy to split the collection fallback, connection reuse, and packaging change if that would make review or later migration easier.