feat: support repartitioning non-partitioned tables

## What type of enhancement is this? - [x] User experience - [x] API improvement ## What does the enhancement do? Currently, `ALTER TABLE ... REPARTITION` / `SPLIT PARTITION` / `MERGE PARTITION` only works on tables that are already partitioned at creation time (using `PARTITION ON COLUMNS`). Non-partitioned tables (with a single default region) cannot be repartitioned into multiple partitions. This is because the `REPARTITION` syntax requires `from_exprs` that match existing region partition expressions: ```sql ALTER TABLE t REPARTITION (from_expr) INTO (to_expr1, to_expr2) ``` For a non-partitioned table, the single default region has an empty partition expression (`""`), which cannot be expressed as a `PartitionExpr`. The `source_region_descriptors` function in `src/meta-srv/src/procedure/repartition/repartition_start.rs:154-189` fails with `RepartitionSourceExprMismatch`. ### Desired behavior Users should be able to partition an existing non-partitioned table without recreating it, e.g.: ```sql -- Currently fails: no way to express "the default region" as from_expr ALTER TABLE my_table REPARTITION () INTO ( ts < '2024-01-01', ts >= '2024-01-01' AND ts < '2024-06-01', ts >= '2024-06-01' ); -- or ALTER TABLE my_table REPARTITION INTO ( ts < '2024-01-01', ts >= '2024-01-01' AND ts < '2024-06-01', ts >= '2024-06-01' ); ``` ## Implementation challenges - The `from_exprs` matching logic in `source_region_descriptors` needs to handle the case where `from_exprs` is empty or a special sentinel representing the default/unpartitioned region. - The `PartitionExpr` type is a structured binary expression (`lhs op rhs`), so there's no natural representation for "the entire key space" or "default partition". A new sentinel value or special handling may be needed. - Data in the single existing region needs to be split and redistributed across the new partitions based on the new partition rules.