Expose scoped scheduling history queries via REST v2 and SDK/CLI

## Background

Scoped scheduling history queries (per-session, per-deployment, per-replica) are already implemented at the repository/service/processor layer and exposed via GraphQL since 26.2.0 (`session_scoped_scheduling_histories`, `deployment_scoped_scheduling_histories`, `route_scoped_scheduling_histories`). However, the REST v2 / SDK / CLI surfaces only expose the admin-level (full search) variants — no scoped equivalents.

This Epic extends the v2 stack to expose all three scoped query variants end-to-end (REST v2 + DTO + Adapter + SDK + CLI), with the additional change of adopting the `replica` naming on the newly created surfaces (Route → Replica). The existing GraphQL `route_scoped_scheduling_histories` query is retained for backward compatibility.

## Scope

- Add REST v2 handlers for the three scoped variants
- Add request/response DTOs under `common/dto/manager/v2/scheduling_history/`
- Wire through `api/adapters/scheduling_history.py`
- Add SDK methods under `client/v2/domains_v2/scheduling_history.py`
- Add CLI commands under `client/cli/v2/scheduling_history/`
- New REST v2 / SDK / CLI surfaces use `replica` (not `route`) for the serving-replica-scoped variant

## Out of Scope

- Repository/service/processor changes (already done)
- GraphQL changes (already exposed)
- Renaming the existing GraphQL `route_scoped_scheduling_histories` query (kept for compatibility)

## Parallelism

The three child Stories can be developed in parallel; the only shared file is `scheduling_history/registry.py` for handler registration, where each story only adds new entries (no conflict).

JIRA Issue: BA-6139

Start by reading the existing admin-level scheduling history handlers and the related paths under common/dto/manager/v2/scheduling_history/. Trace how those surfaces are registered in scheduling_history/registry.py and adapted through api/adapters/scheduling_history.py, then follow the SDK and CLI modules. Done means all three scoped variants work through REST v2, DTOs, the adapter, SDK, and CLI using replica naming for the serving-replica variant.

Written by the indexing model from the issue text.