feat(durable-jobs): add grain-scoped feature handlers - #10679

Problem

DurableJobs currently requires the grain itself to own every job handler. Framework features need activation-local dispatch without changing the grain's public contract. Cancellation also needs distinct semantics for the durable task and its current execution attempt.

Solution

• Add activation-scoped IDurableJobHandlerRegistry and IDurableJobFeatureHandler. Each feature handler is registered once and owns deterministic, side-effect-free name matching through CanHandle(string jobName), supporting exact names, prefixes, or regexes.
• Preserve IDurableJobHandler as the safe grain-author contract: successful return completes the job and exceptions follow retry policy. Feature handlers are the advanced contract which returns an explicit DurableJobRunResult. Both contracts flow through one centralized cancellation, exception, result, metrics, and tracing path.
• Route a uniquely matching job to its feature handler. Jobs with no feature match fall back to IDurableJobHandler; overlapping feature matches fail explicitly as ambiguous. Job names are validated before persistence at manager and shard boundaries.
• Identify active attempts by (JobId, ExecutionGeneration, DequeueCount), which remains stable across duplicate delivery even when RunId changes. Concurrent deliveries share the active invocation; once it reaches a terminal disposition, a later delivery starts a new invocation.
• Treat InProgress as non-terminal: duplicate calls share the current invocation, and the feature handler is invoked again after its requested delay.
• Define CancelAsync as a durable task cancellation request. A true result means removal was durably applied, preventing future attempts; an already-running attempt may still complete cooperatively.
• Define attemptCancellationToken as cooperative cancellation of only the current attempt. Host shutdown or ownership loss stops that attempt while preserving the task for reassignment. Active long polls end promptly on the request while a handler which has not stopped remains active.
• Order attempt reservation and task mutations through the shard so cancellation, start, completion, retry, reschedule, and ownership loss have deterministic outcomes. State-dependent mutation results wait for preceding journal writes, and explicit DurableJobMutationResult values prevent suppressed or unowned mutations from being reported as successful.
• Report cancellation requests, request-operation cancellation, attempt cancellation, and failure as distinct outcomes. Ownership loss cancels the current attempt, is tagged attempt_canceled in shard metrics, and is identified explicitly in logs and mutation activities.
• Keep the registry infrastructure-owned so dispatch and registration remain connected.

Rationale

The simple grain contract makes completion and failure difficult to misuse. The advanced feature contract exposes polling and rescheduling only to components which deliberately opt into the DurableJobs disposition model. Feature handlers compose with existing execution and retry behavior while claiming grain-scoped work using stable name-matching rules. Durable task cancellation governs future delivery; attempt cancellation governs only the current host execution. Handlers own any application-specific idempotency needed when a terminal invocation is delivered again.