[Improvement] Implement fetch and cancel endpoints for async scan planning lifecycle

### What would you like to be improved?
Only the scan-plan submit endpoint (`planTableScan`) is implemented. The async lifecycle defined by the Iceberg REST spec is incomplete: when `planTableScan` returns a `submitted` status with a plan id, clients have no way to poll the result via `GET .../plan/{plan-id}` or cancel it via `DELETE .../plan/{plan-id}`. The sibling `POST .../tasks` endpoint is already tracked in #11284.

### How should we improve?
Implement `fetchPlanningResult` (`GET /v1/{prefix}/namespaces/{namespace}/tables/{table}/plan/{plan-id}`) and `cancelPlanning` (`DELETE .../plan/{plan-id}`), wiring them through the table operation dispatcher and `IcebergExceptionMapper`. Advertise the corresponding endpoints in `/v1/config` and add tests.

Related: scan-planning epic #7668 / #7261; sibling endpoint #11284; spec-compliance epic #10547.

Start with the existing planTableScan flow, then trace the table operation dispatcher and IcebergExceptionMapper. Check how /v1/config advertises endpoints and add coverage for GET and DELETE planning lifecycle operations. Done means clients can fetch and cancel a submitted plan, with the endpoints advertised and tests passing.

Written by the indexing model from the issue text.