Expose kernel & replica-group scheduling history via scope-queryable GraphQL/REST/CLI

## Background

Kernel- and replica-group-level reconcile/status-transition history is already persisted (`kernel_scheduling_history`, `replica_group_history` tables) but is not queryable through any external surface. The session/deployment/route scheduling-history stack already exposes GraphQL/REST/CLI; this Epic extends the same pattern to the two missing domains.

## Scope

Two independent domains, each delivered in two stories (REST+CLI+backend first, then GraphQL on top reusing the adapter/service):

- Kernel scheduling history — data source `kernel_scheduling_history` (writer landed by BA-6852)
- Replica-group scheduling history — data source `replica_group_history` (already written by sokovan lifecycle/scaling appliers)

## GraphQL naming (scoped convention: `scoped\*` prefix, scope as first required arg)

- Kernel: root `scopedKernelSchedulingHistories` / `adminKernelSchedulingHistories`; node fields `SessionV2GQL.kernelHistories` (session_id scope), `KernelV2GQL.schedulingHistories` (kernel_id scope)
- Replica group: root `scopedReplicaGroupSchedulingHistories` / `adminReplicaGroupSchedulingHistories`; node field `ModelDeployment.replicaGroupHistories` (deployment_id scope)

## Notes

- Replica group is a distinct entity from the serving replica (route). The v2 `replica` naming in BA-6139 refers to route; this Epic uses `replica-group` explicitly to avoid collision.
- REST/CLI surfaces must be verified end-to-end with the live `bai` CLI, not just unit tests.

JIRA Issue: BA-6881

Start by reading the existing session, deployment, and route scheduling-history implementations across GraphQL, REST, and CLI, then inspect the kernel_scheduling_history and replica_group_history data sources. Verify the REST and CLI paths end to end with the live bai CLI, and confirm the scoped GraphQL roots and node fields listed in the issue work for both domains.

Written by the indexing model from the issue text.