Relation planning silently ignores unsupported table modifiers

[geoffreyclaude]

Describe the bug

RelationPlanner extensions get the first chance to handle a TableFactor. If every extension returns RelationPlanning::Original, DataFusion's default relation planner currently accepts several table modifiers but silently drops them.

For example, a query such as:

SELECT * FROM my_table TABLESAMPLE SYSTEM (10 PERCENT)

can become an ordinary full table scan. The query succeeds, but it no longer means what the user wrote. The same fall-through pattern exists for version qualifiers, table hints, partition selection, JSON paths, index hints, WITH ORDINALITY, and table-function SETTINGS.

This matters more now that relation planners are being used in real projects to implement exactly this kind of syntax:

• Paimon handles VERSION AS OF and TIMESTAMP AS OF.
• VGI handles TABLESAMPLE.
• Coral explicitly rejects every modifier it does not consume, including exhaustive field matching so a future sqlparser field cannot be ignored by accident.

To reproduce

Register a normal table and plan the TABLESAMPLE query above without a relation extension that claims it (or with a pass-through extension). The resulting plan is an unsampled table scan.

Expected behavior

Extensions should remain free to implement these modifiers. If none does, the default planner should fail closed with a clear “not supported” error rather than execute different semantics.

The default planner should also destructure relevant TableFactor variants exhaustively. That makes a future sqlparser modifier a compile-time decision instead of another possible silent omission.

Additional context

This is a planning-time correctness guard. Queries without these modifiers keep the same planning path.