Flink: Expose scan planning metrics on ContinuousIcebergEnumerator

### Feature Request / Improvement

The Flink ContinuousIcebergEnumerator currently provides no observability into scan planning efficiency. Spark exposes scan metrics via its native metrics system, Flink has no equivalent.

Additionally, BaseIncrementalScan.planFiles() does not emit ScanReport via metricsReporter(), unlike SnapshotScan (batch) which already does.

**Problem**
When running Flink streaming jobs on large Iceberg tables, operators have no visibility into:
- Whether partition pruning is effective (skipped manifests/files)
- How long scan planning takes per cycle (latency spikes)
- How much data is being scanned (file sizes)
- Whether compaction is needed (growing result file counts)

This makes it difficult to diagnose slow streaming pipelines, validate table maintenance effectiveness, or set meaningful SLOs.

**Proposed Solution**
1. Wire metricsReporter() support into BaseIncrementalScan.planFiles(), bringing incremental scans to parity with batch scans (SnapshotScan).
2. Expose all ScanMetricsResult fields as Flink gauges on the ContinuousIcebergEnumerator's coordinator metric group, reporting per-scan (last-value) snapshots.

### Query engine

Flink

### Willingness to contribute

- [x] I can contribute this improvement/feature independently
- [ ] I would be willing to contribute this improvement/feature with guidance from the Iceberg community
- [ ] I cannot contribute this improvement/feature at this time

Start by comparing BaseIncrementalScan.planFiles() with SnapshotScan to trace how metricsReporter() emits ScanReport. Then inspect ContinuousIcebergEnumerator and ScanMetricsResult to map every result field to coordinator metric-group gauges. Done means incremental scans report metrics and the enumerator exposes per-scan last-value gauges for all ScanMetricsResult fields.

Written by the indexing model from the issue text.