Event dispatch: implement dispatcher failure policy and subscriber failure classification

_Filed from an automated code-quality analysis. Verified against source and the unfinished-work report._

## Problem
The framework constitution (§2.6.1 / §2.6.6) distinguishes three publisher-owned dispatcher failure policies — *throw immediately*, *run all then throw aggregate*, *log/handle and continue* — plus subscriber-owned failure classification. The current code models **delivery strategy only**: `SequentialProcessingStrategy` and `ParallelProcessingStrategy` are fail-fast with no configurable policy, `EventStrategyContext` carries no failure-policy reference, and `IEventHandler` has no way to declare failure classification. This is also recorded as an open gap in `docs/reports/unfinished-work.md`.

## Locations
- `src/Elsa/Events/Strategies/SequentialProcessingStrategy.cs:12-19`
- `src/Elsa/Events/Strategies/ParallelProcessingStrategy.cs:8-15`
- `src/Elsa/Events/Contexts/EventStrategyContext.cs:5-12`
- `src/Elsa/Events/Core/Contracts/IEventHandler.cs:9-11`

## Severity / impact
High (architectural / constitution-conformance gap). Without it, a single handler failure breaks the publisher regardless of intended semantics, and publishers can't differentiate critical vs. telemetry-only handlers.

## Proposed remedy
1. Define `IDispatcherFailurePolicy` with `FailImmediately`, `AggregateThenThrow`, `LogAndContinue` implementations.
2. Add a `FailurePolicy` reference to `EventStrategyContext`, threaded from `EventPublisher.Publish(...)`.
3. Apply the policy in both strategies (aggregate vs. fail-fast vs. continue).
4. Add optional subscriber failure-classification metadata to `IEventHandler` (or a sibling contract) so publishers can apply per-handler resilience.
5. Update event-pipeline tests and the extension-point catalog.

Recommend agreeing the contract shape with the maintainer first, since it touches a constitution gate.

Start with constitution §2.6.1/§2.6.6 and the unfinished-work entry in docs/reports/unfinished-work.md, then inspect the two strategy files, EventStrategyContext.cs, IEventHandler.cs, and the EventPublisher.Publish(...) entry point. Confirm the existing event-pipeline tests and agree the contract shape with the maintainer first. Done means both strategies apply the agreed policies and classification, with tests and the extension-point catalog updated.

Written by the indexing model from the issue text.