Replace the concrete-type inventory cast with a capability query

[VDBBjorn]

Closes #155

The false all-clear

OrphanCheckpointHostedService scans a module's checkpoints for processors that no longer exist. To do that it needs a store that can enumerate. The resolution site asked for one by concrete type:

sp.GetKeyedService<ICheckpointStore>(serviceKey) is CachingCheckpointStore caching
    ? caching.AsInventory
    : sp.GetKeyedService<ICheckpointStore>(serviceKey) as ICheckpointInventory

AsInventory was internal, so only one type in the world could answer the question. Any other decorator over an enumerable store — a third party's, or a future one of ours — falls through to the as cast, fails it, and the service quietly receives null. It then does nothing and reports nothing.

That is the shape #155 is about: "we could not look" is indistinguishable from "nothing wrong". The orphan scan is a diagnostic, so a silent no-op is the one failure mode that never surfaces.

The change

ICheckpointInventory grows a capability query:

bool CanEnumerate => true;

The default is opt-in: implementing the interface and saying nothing more means you can enumerate, which is what every direct implementation already meant. A decorator whose inner store cannot enumerate overrides it to false, and CachingCheckpointStore now does exactly that — CanEnumerate => _inner is ICheckpointInventory — replacing the internal AsInventory property. The resolution site stops naming a type:

sp.GetKeyedService<ICheckpointStore>(serviceKey) is ICheckpointInventory { CanEnumerate: true } inv ? inv : null

ListProcessorIdsAsync keeps throwing NotSupportedException as a backstop for a caller that skips the query; the message now says which property to check first.

The seam moves from a concrete type to the interface, so anyone's decorator can answer for itself, and the answer is a fact about the store rather than a fact about which class we happened to recognise.

Tests

OrphanCheckpointTests gains the two halves of the rule, both driving the production DI site rather than a stand-in:

• a third-party decorator over a non-enumerable store overrides CanEnumerate to false and is skipped
• a store that implements ICheckpointInventory and does not override CanEnumerate is still asked for its inventory — the default is opt-in, not opt-out

Whole-file mutation pulled in a large pre-existing gap in CachingCheckpointStore and ServiceCollectionExtensions, so most of the test volume here is unrelated to the change itself: the flush and resync timers, external-reset detection, the monotonic position merge, DisposeAsync's drain and idempotence, fence rejection, and the AddAlberto argument guards. Those were untested before this branch and are tested now. The file also gets a name that describes its subject — CachingCheckpointStoreCoverageTests → CachingCheckpointStoreFlushAndResyncTests — and thirty-four doc comments that cited mutant line numbers now state the rule and the failure it prevents instead.

Fast suite: 1644 passed, 3 skipped, 0 failed (from 1622 on main).

About the mutation gate

Measured locally three times on this branch, adding only tests between runs, each new test hand-verified to kill by breaking the production line: 82.20 % → 81.20 % → 76.32 %. The score falls as verified kills are added.

Run 3 scores ServiceCollectionExtensions.cs:112 — the entire non-sharded RegisterModule call — as survived. Deleting that line by hand fails 62 tests. Two more of its reported survivors are null guards with tests written specifically for them.

So if the Changed code check goes red here, that number is not evidence about this branch. Full write-up with the reproduction is in #167, which is very likely the same upstream problem as #133. Nothing in this PR lowers a threshold, adds a Stryker exclude, or disables a mutant.

[VDBBjorn]

CI note: the red `Changed code` check on this PR is not a score failure. The job was cancelled 42 minutes in (`##[error]The operation was canceled` at 15:35:59) while the runner was wedged — Stryker had reported `115 total mutants will be tested` and never got to a score. No report artifact was produced.

The mutation gate is not a required context for merge. Merging on `build-test` + `pr-policy`, both green. The separate, real problem with this gate — Stryker reporting mutants as survived that the suite demonstrably kills — is tracked in #167 with two hand-verified reproductions.