feat(catalog-rest): client support for server-side REST scan planning

[huan233usc]

Which issue does this PR close?

Part of #1690 — client support for REST server-side scan planning.

Stacked on #2651 (vended storage credentials). The credential commit shown
in this diff comes from #2651; once that merges this branch will be rebased and
the diff will narrow to just the scan-planning changes. This PR reuses
#2651's credential support rather than duplicating it.

What changes are included in this PR?

A client implementation of the REST scan-planning protocol (planTableScan /
fetchPlanningResult / fetchScanTasks). When a catalog advertises the planning
endpoints, a table scan delegates planning to the server and consumes the
returned FileScanTasks; otherwise it transparently falls back to native
client-side planning.

Design

The feature hangs off a single seam — TableScan::plan_files() — so execution
(to_arrow, the Arrow reader) is untouched and DataFusion needs no changes.

Table::scan() ─► TableScan::plan_files()
   │ injected ScanPlanner present?
   ├─ no  ─► native manifest planning (unchanged)
   └─ yes ─► ScanPlanner::plan_table_scan(ScanPlanRequest)
                │ endpoint negotiation: gate on GET /v1/config `endpoints`
                ▼
   POST .../plan ─► COMPLETED ─────────────────────────────┐
                 └─► SUBMITTED ─► poll GET .../plan/{id}     │ (exp backoff)
   plan-tasks? ─► POST .../tasks (tokens may recurse) ───────┤
                                                             ▼
   convert wire content-files ─► FileScanTask (public builders)
   + build a plan-scoped FileIO from vended `storage-credentials`
     via FileIOBuilder::with_prefixed_props (from #2651)
                                                             ▼
   ServerScanPlan { tasks, file_io } ─► to_arrow() reads tasks through file_io
   (on Drop before completion: best-effort DELETE .../plan/{id})

Components

1. Injection seam — a narrow ScanPlanner capability trait
   (crates/iceberg/src/scan/planner.rs); Table carries an optional
   Arc<dyn ScanPlanner>; plan_files() delegates and falls back on
   FeatureUnsupported. The core Catalog trait is untouched.
2. Endpoint negotiation — CatalogConfig parses the endpoints field of
   GET /v1/config; scan-plan calls are gated by Endpoint::check.
3. Wire DTOs — plan / fetch-planning-result / fetch-scan-tasks types plus a
   lean content-file shape.
4. State machine — submit → poll-with-backoff → recursive fetchScanTasks,
   with best-effort cancel on drop.
5. Conversion — wire content-files → FileScanTask via the public builders;
   the scan's own bound filter is the per-task predicate, pushed down as Iceberg
   expression JSON when losslessly encodable.
6. Credential reuse — ScanPlanner::plan_table_scan returns
   ServerScanPlan { tasks, file_io }; the planner builds the plan-scoped
   FileIO from the vended storage-credentials using feat(rest): support vended storage credentials with per-prefix FileIO #2651's
   FileIOBuilder::with_prefixed_props (no duplicate credential machinery).

Alternative injection design

The same feature with planning placed on the Catalog trait
(Catalog::plan_table_scan, Table holding Arc<dyn Catalog>) is in
huan233usc#2 for comparison. This PR uses
the narrow-trait design because it keeps the central Catalog trait minimal and
avoids giving every Table a back-reference to the full catalog.

Future work (design feedback welcome)

Native planning stays inline in plan_files() here; a follow-up could generalize
ScanPlanner into the single planning abstraction (a NativeScanPlanner peer +
a FallbackScanPlanner that composes server→native), making plan_files() a
one-liner with no branch. Deferred to keep this PR focused.

Are these changes tested?

Yes — unit tests for the wire DTOs, endpoint codec, and expression-JSON
serialization, conversion tests, and end-to-end mockito tests covering the
completed-inline, submitted-then-polled, and recursive plan-task fan-out paths.