REST scan planning: local-vs-remote parity test (Phase 6 follow-up)

Follow-up to #1494 (part of #1178, Phase 6).

#1494 landed a scenario-driven, client-conformance fake REST scan-planning server at `catalog/rest/internal/planfake/`. It drives the low-level REST scan-planning client against independently authored wire payloads, but it does not itself plan — so it cannot yet power the epic's stated acceptance test.

## Goal

Add the local-vs-remote parity test from the #1178 correctness contract: the same scan (same filter, same table, same snapshot) under `scan-planning-mode=local` and `scan-planning-mode=remote` must produce the identical `FileScanTask` set (paths, ranges, deletes, residuals).

## Notes

- Needs a fixture that runs real planning server-side (e.g. the in-memory planner sketched in #1178 Phase 6) so the remote path returns real results, or an equivalent that makes the comparison meaningful.
- This is the highest-risk validation in the epic — silent expression/wire-codec divergence is the failure mode — so it should cover schema-evolution and `use-snapshot-schema` edge cases.
- Depends on Phase 5 (scanner delegation) being wired.

Start with the fake REST scan-planning server in catalog/rest/internal/planfake/ and read the Phase 6 contract in #1178, along with the scanner delegation work from Phase 5. Add a fixture that performs real server-side planning, then compare local and remote results for the same filter, table, and snapshot, including schema evolution and use-snapshot-schema cases. Done means both modes produce identical FileScanTask sets.

Written by the indexing model from the issue text.