[BUG] Expression index with to_date/to_timestamp + format is never selected by real queries; test harness feeds shapes production never produces

**Describe the problem you faced**

The expression-index filter matcher has the same optimizer-boundary bug that #19446/#19474 fixed for column-stats data skipping.

`ExpressionIndexSupport.extractQueryAndLiterals`'s `attributeFetcher` matches the analysis-time `ParseToDate` / `ParseToTimestamp` shapes, but the `queryFilters` it receives are `HoodieFileIndex` dataFilters -- post-optimizer, because Hudi's pruning rule is injected via `injectOptimizerRule` and runs after the FinishAnalysis batch (ReplaceExpressions). For the explicit-format form the real shape is `GetTimestamp(col, fmt)`, which falls through to `case other => other` (the UnaryExpression arm does not match a BinaryExpression), and `RecordLevelIndexSupport.getAttributeLiteralTuple` then requires a bare `AttributeReference`, so no index match happens. Net effect: an expression index created with `expr='to_date', format=...` or `expr='to_timestamp', format=...` cannot be selected by a real SQL query.

**Why no test catches it**

Every case in `TestExpressionIndex` (around lines 1681-1714) builds the filter with `resolveExpr` -- analyzer only, no optimizer -- and calls `fileIndex.listFiles` directly via `verifyFilePruning`. The harness therefore feeds analysis-time shapes that production never delivers. This is the exact blind spot that hid #19446.

**Suggested fix**

1. Lift the `fullyOptimize` helper added in #19474 (session optimizer over a `HoodieDummyExpressionHolder`) into a shared test util and run `verifyFilePruning` filters through it. Expect several existing `TestExpressionIndex` cases to go red -- that is the point.
2. Add a `GetTimestamp` arm to `attributeFetcher`, with the same soundness considerations #19474 applied to the data-skipping whitelist (literal format, ANSI/failOnError semantics, null on unparseable input).

**Environment**: master (found during review of #19474; matcher logic verified by reading, end-to-end consequence deduced, not executed).

Start with ExpressionIndexSupport.extractQueryAndLiterals and its attributeFetcher, then inspect TestExpressionIndex around lines 1681-1714 and the verifyFilePruning harness. Read the fullyOptimize helper from #19474 and run the expression-index tests with optimized filters. Done means production-shaped GetTimestamp filters are matched safely and the affected cases pass with literal-format and null/error semantics covered.

Written by the indexing model from the issue text.