bug: PR #26284 导致 Big Data Test INSERT...SELECT...ORDER BY spill 磁盘满（no space left on device），级联 inner join 返回 count=0

## 问题

PR #26284 (`fix: distribute sink scan shuffle hashbuild`) 合入后，Big Data Test 的 `insert_into_table_limit` 数据灌入失败（磁盘满），导致下游 inner join 查询返回 count=0。

## 影响范围

- **Workflow**: Big Data Test (4.2-dev)
- **CI Run**: https://github.com/matrixorigin/mo-nightly-regression/actions/runs/30383337080
- **Commit**: `36cae2e15b`（PR #26284 合入后首个 4.2-dev nightly）

## 失败链

### Step 1: Limit Insert 失败

```sql
insert into big_data_test.insert_into_table_limit
select * from big_data_test.table_basic_for_load_100M
order by col4 limit 5000000
```

```
Error 20101: write /tmp/mo-top-spill-2130408090: no space left on device
```

top-N sort 的 spill 文件写满 `/tmp`。表 `insert_into_table_limit` 为空（count=0，期望 5,000,000）。

### Step 2: Inner Join 查询结果为空

```sql
select count(*) from big_data_test.insert_into_table_limit
inner join big_data_test.table_basic_for_load_100M
on ...col1 = ...col1 limit 300000
```

- Expected: count(*) = 1,953,128,852,937
- Actual: **count(*) = 0**（因为 `insert_into_table_limit` 是空表）

## 时间线

| 日期 | Commit | Limit Insert | Inner Join |
|---|---|---|---|
| 07-24 ~ 07-27 | 0069d64 / fec60ad | ✅ | ✅ |
| **07-28** | **36cae2e** | ❌ no space left | ❌ count=0 |

退化恰好发生在 PR #26284 合入当天。

## 根因分析

### PR #26284 的变更

将 SINK_SCAN 相关的 shuffle hash-build 接收方从集中在 coordinator 1 个 CN，改为分发到所有 query worker CN（3 个）：

```go
// Before: 1 个接收节点
stageNode = scopeNodeWithMcpu(stageNode, 1)
return engine.Nodes{stageNode}, true

// After: 所有 query worker 参与
stageNodes := c.queryWorkerStageNodes()
```

### 资源影响

- **之前**：shuffle 集中在 1 个 CN，资源压力集中但可控
- **之后**：分发到 3 个 CN 并行执行，所有 CN 同时做更多并发操作 → 内存更紧张 → top-N sort 更早/更多 spill → `/tmp` 撑满

### 环境配置缺陷

CN pod **没有配置 ephemeral-storage limit**，也没有 emptyDir volume 给 `/tmp`，spill 文件直接写在节点根文件系统上。

```yaml
# big-data-tke.yaml CN 配置
tp:
replicas: 3
resources:
requests:
cpu: 14
memory: 55Gi
limits:
cpu: 14
memory: 55Gi
# ⚠️ 没有 ephemeral-storage limit
# ⚠️ 没有 emptyDir volume for /tmp
```

## 建议

1. 排查 PR #26284 是否改变了 INSERT...SELECT...ORDER BY 的执行计划（EXPLAIN 对比前后）
2. 给 CN pod 的 `/tmp` 配 emptyDir 或 ephemeral-storage limit，隔离 spill 存储
3. 考虑给 spill 路径加大小限制，避免无限 spill

/cc @jiangxinmeng1