[Bug]: multi-CN JOIN on a range-partitioned table panics in CombinedRelData.Split

## Description

An INNER JOIN over a non-empty range-partitioned table returns an internal
`panic not implemented` error when the query is scheduled on multiple CNs.
The failure occurs before join spill is reached: `CombinedRelData.Split` is
called from the generic remote-reader construction path, but that method is
explicitly unimplemented for combined (partitioned-table) relation data.

## Environment

- Branch: `main`
- Commit: `15a2d07c687a62a0984cf62846b092912a28c0f1`
- Deployment: isolated local cluster with 1 LOG, 1 TN, and 2 CN services.
- Coordinator endpoints tested independently: CN1 and CN2.
- `join_spill_mem` was set to `1073741824`, so the error is not caused by a
low spill-memory threshold or a spill-file operation.

## Steps to reproduce

Use a populated range-partitioned table. The fixture used in this run is
`spill_blackbox_matrix.plan_l`, whose relevant definition is:

```sql
CREATE TABLE plan_l (
tenant INT NOT NULL,
seq BIGINT NOT NULL,
-- other columns are not relevant to this failure
PRIMARY KEY (tenant, seq)
)
PARTITION BY RANGE (tenant) (
PARTITION p0 VALUES LESS THAN (16),
PARTITION p1 VALUES LESS THAN (32),
PARTITION p2 VALUES LESS THAN (48),
PARTITION p3 VALUES LESS THAN (MAXVALUE)
);
```

The tested fixture contains 160000 rows. On either CN coordinator, run:

```sql
USE spill_blackbox_matrix;
SET SESSION optimizer_hints = "execType=2";
SET SESSION join_spill_mem = 1073741824;

EXPLAIN
SELECT COUNT(*)
FROM plan_l AS l
JOIN plan_l AS r ON l.seq = r.seq;

SELECT COUNT(*)
FROM plan_l AS l
JOIN plan_l AS r ON l.seq = r.seq;
```

`EXPLAIN` reports `AP QUERY PLAN ON MULTICN(8 core)` and an INNER Join with
two scans of `plan_l`.

## Actual behavior

The SELECT fails with MySQL error 20101:

```text
internal error: panic not implemented:
github.com/matrixorigin/matrixone/pkg/vm/engine/disttae.(*CombinedRelData).Split
pkg/vm/engine/disttae/txn_table_combined.go:1220
github.com/matrixorigin/matrixone/pkg/vm/engine/disttae.(*Engine).BuildBlockReaders
pkg/vm/engine/disttae/engine.go:1163
github.com/matrixorigin/matrixone/pkg/sql/compile.(*Scope).buildReaders
```

## Expected behavior

A supported multi-CN JOIN over a range-partitioned table should return its
result without an internal panic. For this fixture, the result should be
`160000` rows.

## Stability and controls

- Reproducer: 3/3 failures on CN1; the same failure also occurred when CN2
was the coordinator.
- Multi-CN scan control: `SELECT COUNT(*) FROM plan_l` completed and returned
`160000`.
- One-CN control: with optimizer hints cleared and the same 1 GiB join budget,
the JOIN completed with `COUNT(*) = 160000` and both decimal sums equal to
`128000800.0000`.
- Post-failure health: both CNs immediately accepted `SELECT 1` and remained
`Working` in `SHOW BACKEND SERVERS`.
- Cleanup: no spill files remained in the CN spill directory. This is expected
because the failure precedes spill allocation.

## Code analysis

`combinedTxnTable.Ranges` returns `*CombinedRelData` for the range-partitioned
relation. During remote reader construction, `Engine.BuildBlockReaders` calls
`relData.Split(newNum)`. `CombinedRelData.Split` currently contains
`panic("not implemented")`. This identifies the failing boundary; the intended
partitioned-reader ownership across the multi-CN path needs confirmation by
the component owner.

## Duplicate search

Searched both open and closed MatrixOne issues and pull requests for
`CombinedRelData Split`, `BuildBlockReaders`, `multi CN join panic`,
`multicn join`, and `partition table join`; no matching report was found.
Issue #25862 concerns multi-CN runtime-filter performance for RIGHT SINGLE
joins and is not this partitioned-table panic.

## Regression coverage

After the product fix, add a two-CN motr scenario (or equivalent distributed
SQL regression) that creates/populates a range-partitioned table, verifies the
multi-CN plan, and asserts this JOIN result. The regression must not use the
current panic as an expected baseline.