Follow-up: evaluate cancellation-safe DID resolution single-flight

## Context

Issue #45 deliberately keeps the generic cache decorator runtime-neutral and permits duplicate-safe concurrent fills. Hiding blocking synchronization in the domain crate would risk executor stalls and cancellation deadlocks.

## Trigger

Start implementation only after at least two independent SDK consumers or adapters demonstrate the same request-coalescing requirement and cancellation semantics.

## Expected outcome

- Compare outer-adapter coordination with an optional SDK coordinator.
- Specify cancellation recovery, waiter wake-up, timeout, panic/drop, and retry behavior before code.
- Preserve Send + Sync portability across native, mobile, and wasm targets.
- Prove that no blocking mutex or executor-specific dependency leaks into identus-did.
- Add load/performance evidence and adversarial cancellation tests.

## Non-goals until triggered

No single-flight implementation is required for #45. Duplicate concurrent origin calls remain an explicit and tested contract; cache correctness and boundedness do not depend on coalescing.

Related: #5, #20, #45.

Start with related issues #5, #20, and #45, especially the generic cache decorator contract and the identus-did portability constraint. Wait for at least two independent SDK consumers or adapters to demonstrate the requirement, then compare outer-adapter coordination with an optional SDK coordinator. Done means cancellation, wake-up, timeout, panic/drop, retry, portability, and load-test behavior are specified and adversarial tests provide evidence without blocking or executor-specific dependencies leaking into identus-did.

Written by the indexing model from the issue text.