fix(keychain): retry the Linux read path when the collection relocks

[Benehiko]

What

#557 made the Linux keychain write path relock-aware (it landed withRelockRetry and wrapped Save's CreateItem/SetItemSecret/duplicate-collapse DeleteItem, and Delete's DeleteItem). The read path was deliberately left for a focused follow-up — this PR.

Get and Filter (via loadSecret) call GetSecret directly. That call is subject to the same gnome-keyring relock race the write path was: the store dials a fresh D-Bus connection per operation, and a prior operation's closing connection can relock the collection asynchronously — after IsLocked reports it unlocked but before the GetSecret runs — surfacing an intermittent org.freedesktop.Secret.Error.IsLocked error.

How

Wrap both GetSecret call sites in the withRelockRetry helper already on main:

• Get → the single-item GetSecret.
• Filter → loadSecret's GetSecret. loadSecret now takes the enclosing collectionPath so it can re-unlock on a relock.

No new mechanism — this reuses the exact helper merged in #557 (react to the authoritative locked D-Bus error, bounded exponential backoff, abort immediately if Unlock itself fails). After this, all lock-gated operations (reads and writes) are uniformly relock-robust.

Context

This is the read-path remainder of the now-closed #560. #557 superseded the rest of #560 (its helper, its Delete wrap, and its obsolete pre-#557 Save wrap); only the read-path coverage was outstanding, and that is what this PR adds.

Tests

• Fake-backed: TestKeychainGetRetriesWhenCollectionRelocks, TestKeychainFilterRetriesWhenCollectionRelocks — two leading locked failures then a success; assert the retry count and one Unlock per retry.
• Real gnome-keyring: full store/keychain package green on the ubuntu-24-gnome-keyring and fedora-43-gnome-keyring CI harnesses.
• Lint clean (golangci-lint v2.12.2, all platforms, 0 issues).

🤖 Generated with Claude Code

[docker-agent]

Assessment: 🟢 APPROVE

No bugs found in the changed code.

The PR correctly extends the withRelockRetry helper to both read paths:

• Get: the single-item GetSecret call is now wrapped in withRelockRetry.
• Filter / loadSecret: loadSecret now accepts collectionPath so it can re-unlock on relock, and its GetSecret call is similarly wrapped.

The collectionPath parameter is threaded through correctly, defer clear(value) is registered only after a successful withRelockRetry return (matching the pre-existing pattern), and the new tests (TestKeychainGetRetriesWhenCollectionRelocks, TestKeychainFilterRetriesWhenCollectionRelocks) properly exercise two leading locked failures then a success, asserting retry count and one Unlock call per retry. No issues detected.