build: centralize backend dependencies on current Planner main

[zzylol]

Why

Keep the backend control plane, data plane, and shared types on the same Planner source when updating the integration. Backend main already pins the latest Planner main, 3be523fa0f06a905188e42cbe482d06aa843ba5d; this PR does not claim a version upgrade.

What and how

Move the four Planner dependency definitions into workspace dependencies and inherit them at all eight use sites. Preserve the resolved source and Cargo.lock. Update the offline replay wrapper to read its pinned revision from the workspace manifest and remove obsolete per-crate migration comments.

Before this PR

Updating a Planner package required editing duplicate definitions across member manifests; for example, planner-types was pinned separately in three crates.

After this PR

Those three crates inherit one planner-types definition. All four Planner packages are maintained together in the root manifest. The offline report still records the same Planner revision. Query planning and serving behavior are unchanged.

Verification

• cargo +1.98.0 metadata --locked --no-deps: all eight declarations resolve to the same Planner source at current main.
• Offline wrapper smoke check with Cargo execution mocked: report records the expected workspace pin.
• cargo +1.98.0 check --locked -p control_plane -p data_plane: passed (existing data-plane warnings).
• cargo +1.98.0 test --locked -p control_plane planner_selection: 10 passed.
• cargo +1.98.0 test --locked -p control_plane clickhouse::tests: 6 passed.
• Shared-workload Python tests: 4 passed.
• Rust validation used an isolated source copy with the CI-pinned sketchlib checkout and the existing local Collector dependency.

This is dependency integration maintenance. It does not provide unified Prometheus/ClickHouse/VictoriaMetrics benchmarking or new runtime capabilities. Live database performance measurements are not applicable to this manifest-only integration change.