Relation planning silently ignores unsupported table modifiers

## 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:

```sql
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`](https://github.com/apache/paimon-rust/blob/8001f02d8cc33bd3d5d77a1e7de781ff3add28d6/crates/integrations/datafusion/src/relation_planner.rs#L86-L104).
- [VGI handles `TABLESAMPLE`](https://github.com/Query-farm/vgi-datafusion/blob/c6e3a6cfb05202a61233aa535912d8e2faae3e6e/src/sampling.rs#L65-L76).
- [Coral explicitly rejects every modifier it does not consume](https://github.com/withcoral/coral/blob/8678de77aba0faed532e9b43995702a835dacca4/crates/coral-engine/src/runtime/scoped_table_functions.rs#L180-L223), 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.

Start at DataFusion's default RelationPlanner handling of TableFactor, after relation-planner extensions return RelationPlanning::Original, and reproduce the TABLESAMPLE query described in the issue. Trace the other listed modifiers and add coverage where appropriate; done means unsupported modifiers produce a clear planning error, supported extensions still handle them, and relevant TableFactor variants are matched exhaustively.

Written by the indexing model from the issue text.