feat!: thread CancellationToken through ICredentialManager

[StuartMeeks]

Fixes #74. Breaking — this makes the next release 2.0.0.

What changed

Every ICredentialManager member gains a trailing CancellationToken cancellationToken = default.

• Callers are unaffected — the parameter is optional, so existing consumer code compiles unchanged.
• External implementations must update their signatures. That is the breaking part.
• ICredentialCollector and ICredentialSummaryProvider are untouched, so the provider packages are unaffected.

The libsecret backend binds the token to a GCancellable per call. g_cancellable_cancel is thread-safe by contract, which is the whole point — it fires from the token callback while another thread sits blocked inside a synchronous libsecret call. A cancelled call surfaces as OperationCanceledException rather than a generic wrapped GError, because cancellation is checked before the GError is translated.

The Keychain backend honours the token at entry. SecItem* takes no cancellable, so there is no mid-call cancellation there — documented, not faked.

It does not fix the KWallet wedge, and I checked rather than assumed

This is the part worth your attention. I instrumented the KWallet scenario to see whether cancellation actually escapes it:

main thread 1 entering AddCredentialAsync
  [4.0s] pool thread alive, requesting cancel
  [4.0s] token callback FIRED on thread 4
  [4.0s] cts.Cancel() returned
libsecret-WARNING: received unexpected result type ao from Completed signal instead of expected o
GLib-GIO-CRITICAL: GTask secret_service_real_prompt_async ... finalized without ever returning

The cancellation works — the callback fires, on time, on a pool thread, while the main thread is blocked. The call still never returns, because ksecretd emits the prompt's Completed signal with an ao payload where libsecret expects o. libsecret's prompt GTask is then abandoned without ever returning, so the nested main loop the synchronous wrapper runs never exits. Cancellation cannot rescue a task libsecret has already given up on.

That is an upstream libsecret/KWallet incompatibility. It is recorded in LibsecretCredentialManager's remarks with the exact log lines, and the interface remarks now say plainly that honouring a token is not a guarantee every block is escapable. I had written the opposite in an earlier draft of these docs and corrected it once the experiment disproved it.

So: the API is now cancellable, which is what was chosen and is worth having. KWallet remains unsupported for the reason #19 already documented.

Verification

Build clean, 416 tests (358 passed, 58 skipped), up from 412.

New tests assert that an already-cancelled token surfaces as OperationCanceledException on both the file and libsecret backends — the libsecret one proves the GCancellable path is reached, since that is where the cancellation is observed.

One suppression, deliberately

xUnit1051 is now suppressed in the test project. It fires at 530 call sites into ICredentialManager the moment its members accept a token. Threading one through every existing assertion would bury the actual change in mechanical noise for a benefit — prompter teardown of sub-second tests — that does not apply here. The rationale is written into the csproj alongside the existing suppressions. New cancellation tests pass a real token explicitly.

Not in this PR

The version bump. [Unreleased] records that this makes the next release 2.0.0; cutting it is a separate release PR, matching #40.

🤖 Generated with Claude Code