Extract a shared base for runtime scheduler work handlers (DRY)

_Filed from an automated code-quality analysis. Verified against source. Related to #253 (scheduler feature)._

## Problem
The runtime scheduler work handlers repeat the same building blocks across ~8 files: a near-identical try/catch JSON payload-deserialization block, a `ValidatePinnedExecutable()`-style validation body, and several private `New*()` factory methods that construct work items and post-commit intents. Any change to deserialization or validation must be applied in every handler.

## Locations
- `src/Elsa/Workflows/Runtime/Core/Services/WorkflowStartSchedulerWorkHandler.cs`
- `src/Elsa/Workflows/Runtime/Core/Services/WorkflowStartActivitySchedulerWorkHandler.cs`
- `src/Elsa/Workflows/Runtime/Core/Services/WorkflowScheduleActivitySchedulerWorkHandler.cs`
- `src/Elsa/Workflows/Runtime/Core/Services/WorkflowCheckpointSchedulerWorkHandler.cs`
- …and the other `*SchedulerWorkHandler.cs` peers in the same folder.

## Severity / impact
Medium. Duplication across critical runtime handlers; inconsistent validation/deserialization risk.

## Proposed remedy
Introduce a `SchedulerWorkHandlerBase` abstract class providing `DeserializePayload(...)` and shared pinned-executable validation, and extract a `RuntimeSchedulerWorkItemFactory` for the repeated work-item/intent construction. **Note:** issue #253 reports the scheduler solution currently does not compile — coordinate with / sequence after that fix before refactoring.

Start by reviewing issue #253 and the listed handlers in src/Elsa/Workflows/Runtime/Core/Services/, then inspect the other *SchedulerWorkHandler.cs peers for the repeated deserialization, validation, and factory patterns. Coordinate with the scheduler compilation fix before refactoring. Done means the shared base and RuntimeSchedulerWorkItemFactory cover the repeated work while the scheduler solution compiles.

Written by the indexing model from the issue text.