feat(om): use Orleans 10.4 cancellation-aware reminder APIs

[egil]

Release Baseline

All OM packages in this release will consistently require Orleans 10.4.0; the Journaling dependency is 10.4.0-alpha.1. Consumers must upgrade Orleans along with OM. This supersedes the earlier 10.3.1 runtime-compatibility requirement. Preserve persisted-data compatibility and recovery evidence. Optional #283/#284 remain deferred.

Context

dotnet/orleans#10937, released in Orleans 10.4.0, adds cancellation-aware reminder registration, lookup, removal and IRemindable.ReceiveReminder overloads. Legacy overloads remain, and the default token-aware callback delegates to the legacy callback.

OM currently uses the legacy registration/lookup/removal overloads. Activation/deactivation often cancel only a WaitAsync wrapper, leaving the underlying operation running; IOutboxGrain and IOutboxComponent.ReceiveReminderAsync route only the two-argument callback. This is an adoption improvement after #285, not a prerequisite compile fix.

Work

• Route the cancellation-aware callback into the processor and its posting path where appropriate, with a trailing CancellationToken.
• Use the new reminder I/O overloads where a token represents the lifetime of the operation. Explicitly distinguish cancellation of one caller's wait from cancellation of a shared reminder mutation.
• Preserve serialized reminder mutation, reconciliation of in-flight operations, and the best-effort durable handoff on deactivation. Cancellation or an ambiguous response must not be interpreted as proof that a reminder was created/deleted.
• Preserve both reminder policies: active retries use grain timers; OnDeactivation avoids normal reminder existence lookups; KeepRegistered retains its fallback. Do not increase reminder API calls simply to implement cancellation.
• Revise callback forwarding examples and explain changes for grains that handle their own reminder names.

Acceptance

• Pre-cancelled and in-flight operations exercise actual token forwarding, rather than only cancelling the await.
• Reminder-driven dispatch can observe the token; cancelled delivery leaves messages pending and unacknowledged.
• Concurrent registration/removal, deactivation deadlines and ambiguous removal keep local handle/cadence state coherent and preserve recovery.
• One cancelled waiter does not inadvertently cancel a shared mutation required by another caller.
• Legacy and token-aware callbacks work, including grains with custom reminder handlers; dispatch does not bypass application handling or recurse.
• Existing reminder call-count and recovery behavior remain proven for both policies.

Public IAsyncStream subscription/publish APIs did not gain equivalent token overloads in this PR; do not expand this issue into forwarding tokens to nonexistent APIs.

Reviewed against OM source at 2b5d24614ff08a9028ebc61995308176dbb90841; current main at fcca835c3141ac32874c70f687583d2c49ae4847 differs only in OM's version file.