[FLINK-40540][table-planner] Put the rule's reason first in the planning error

[MartijnVisser]

What is the purpose of the change

When a rule rejects a query during the Volcano phase, FlinkVolcanoProgram wraps the exception as "Cannot generate a valid execution plan for the given query:" followed by the full logical plan and only then the rule's own message, so the actionable sentence is buried. A ValidationException thrown from a rule's onMatch() is not caught at all and reaches users as Calcite's "Error while applying rule ..." RuntimeException.

This change keeps the wrapper and its cause chain, so nothing matching on the header, the type or the cause is affected, but puts the rule's reason on the header line and lists the plan after a Plan: marker so that tools rewriting the message can find it:

Cannot generate a valid execution plan for the given query: Window SessionGroupWindow('w$, ts, 1800000) is not supported right now.

Plan:
FlinkLogicalWindowAggregate(window=[SessionGroupWindow('w$, ts, 1800000)], select=[COUNT(*) AS cnt])
+- ...

Brief change log

• FlinkVolcanoProgram builds one message layout for CannotPlanException and for a TableException or ValidationException thrown by a rule, looking through Calcite's RuntimeException wrapper; other exceptions propagate unchanged
• Drops the "Sql optimization: " prefix and the "Please check the documentation" trailer from rule rejections

Verifying this change

This change is already covered by existing tests: all assertions on the header text, exception type and cause chain pass unchanged (./mvnw verify for flink-table-planner). Added assertions for the new layout in GroupWindowTest#testNonPartitionedSessionWindow and OverAggregateTest#testExclusionGroupIsNotSupported, and unit tests for FlinkVolcanoProgram#unwrapRuleException.

Does this pull request potentially affect one of the following parts:

• Dependencies (does it add or upgrade a dependency): no
• The public API, i.e., is any changed class annotated with @Public(Evolving): no
• The serializers: no
• The runtime per-record code paths (performance sensitive): no
• Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Kubernetes/Yarn, ZooKeeper: no
• The S3 file system connector: no

Documentation

• Does this pull request introduce a new feature? no
• If yes, how is the feature documented? not applicable

---

Was generative AI tooling used to co-author this PR?

• Yes (please specify the tool below)

Generated-by: Claude Code (Claude Fable 5.1)

[flinkbot]

CI report:

• cc04471 Azure: SUCCESS

Bot commands

The @flinkbot bot supports the following commands:

• @flinkbot run azure re-run the last Azure build

[MartijnVisser]

@flinkbot run azure