[Task]: Expand core benchmark coverage

[rian-be]

Summary

Expand the benchmark coverage for the core mutation runtime so performance characteristics stay visible as the engine evolves.

Goal

Provide benchmark umbrella for the core runtime that can be used to track throughput, policy overhead, concurrency effects, and execution pipeline costs as the codebase changes.

Problem

The repository already includes benchmark project, but the current coverage is too narrow to act as reliable performance bar for the core runtime. As new behavior is added to the engine, policies, interceptors, and execution pipeline, it becomes harder to tell whether change introduces meaningful overhead or improves throughput.

A benchmark umbrella issue gives the repo clear place to grow performance coverage without mixing it into runtime features or test cleanup. It also makes it easier to split benchmark work into smaller, focused subissues as specific hotspots are identified.

Scope

• Review the current core benchmark coverage and identify missing runtime hotspots
• Expand benchmark coverage for the mutation engine's main execution paths
• Add benchmark scenarios for policy evaluation overhead
• Add benchmark scenarios for concurrency and contention where they materially affect runtime behavior
• Add benchmark scenarios for interception, diagnostics, or result materialization if those paths are hot enough to measure
• Keep benchmarks focused on the core runtime rather than governance or Redis provider concerns unless a separate issue explicitly needs them
• Organize benchmark work into smaller subissues where the scope would otherwise become too broad

Design Expectations

• Benchmarks should measure meaningful runtime behavior rather than synthetic micro optimizations.
• Each benchmark should map to real mutation runtime concern.
• Benchmark names should reflect the scenario being measured.
• The benchmark project should stay easy to extend as new runtime surfaces are added.
• If benchmark data requires setup helpers, those helpers should be local to the benchmark domain and not leak into production code.

Suggested Coverage Surface

• mutation engine throughput
• policy evaluation overhead
• interceptor and diagnostics overhead
• batch execution cost
• concurrency gate or contention behavior
• mutation result and side-effect materialization

Acceptance Criteria

• The benchmark project has clear roadmap for the core runtime hotspots that matter most
• Core mutation runtime performance can be measured across more than one execution shape
• Benchmark scenarios are named and organized by runtime concern
• Benchmark work can be split into focused subissues without rewriting the umbrella issue
• The benchmark scope stays centered on the core runtime

Non-Goals

• This issue does not change runtime behavior
• This issue does not add benchmark coverage for every example project or provider
• This issue does not require full performance lab or load testing environment
• This issue does not optimize code just to make the benchmarks look better

Notes

This issue is intended as benchmark umbrella. Concrete hotspot work should be split into subissues once the target scenario is clear.