Simplify replica group rollout scaling to a single desired count with a creation-revision pointer

Follow-up refactor of BA-6998. The replica group currently tracks two desired counts (desired_current_replica_count / desired_target_replica_count) that the rolling lifecycle handler steps with surge/unavailable formulas, while the scaling reconciler fills each side independently. Since BA-6998 made the outgoing revision drain-only during a rollout (never refilled, freed capacity hands over to the target immediately), the same behavior can be expressed with a simpler model: one total desired count on the group plus a pointer to the revision that new routes are created with. Scaling always creates missing replicas with the newest (target) revision and drains surplus preferring the oldest; the rollout completes when no old-revision replicas remain.

Notes: per-revision live/serving counts must be kept — the no-downtime gate (only drain old replicas when enough new ones are serving) and the max_surge / max_unavailable budgets still need them; the step math relocates rather than disappears. Scope includes the replica_groups schema (dropping one desired-count column, migration), the scaling reconcile and rolling/draining lifecycle handlers, promotion, and history recording. Behavior-preserving: the BA-6998 live-test scenarios (old side fully terminated mid-rollout, surge pacing on a healthy old side) must keep passing.

JIRA Issue: BA-7015

Start by tracing the replica_groups schema, scaling reconcile, rolling and draining lifecycle handlers, promotion, and history recording. Review the BA-6998 live-test scenarios, especially an old side terminated mid-rollout and surge pacing with a healthy old side. Done means the migration and behavior-preserving scenarios pass with one group desired count and a creation-revision pointer.

Written by the indexing model from the issue text.