[Bug]: Client deadline returns cancellation but long DML still commits

## Description

客户端对一个已发送的长时间 DML 设置短 deadline 后，`ExecContext` 已返回 `context deadline exceeded`，但 MatrixOne 仍在客户端返回后继续执行并完整提交该 DML。调用方会把操作视为失败并可能重试，从而产生重复写入风险。

## Environment

- Branch: `main`
- Commit: `ae2af58bf4b4feaeb65ddb85a59a1e10fb80bc53`
- Deployment: 本地双 CN 验证（分别通过 CN1、CN2 连接，同一集群）
- Date: `2026-08-07`

## Steps to reproduce

以任一 CN 建表：

```sql
create database prepared_cancel;
use prepared_cancel;
create table dst(id bigint primary key, v bigint);
```

Go 客户端使用 `context.WithTimeout(ctx, 5*time.Millisecond)` 执行以下任一语句：

```sql
-- 直接执行
insert into dst
select result, result + 1 from generate_series(1, 2000000) g;

-- binary prepared statement
insert into dst
select result, result + ? from generate_series(1, 2000000) g;
-- ExecContext(cancelCtx, 1)
```

客户端收到 deadline 错误后，使用新连接立即及持续轮询：

```sql
select count(*) from dst;
```

## Actual behavior

- `ExecContext` 在 5ms deadline 后返回 `context deadline exceeded`。
- 新连接刚建立时 `count(*) = 0`，随后在 3 秒观察窗口内变为 `2000000`。
- 即：客户端已经收到取消结果，但服务端仍完整提交了原 DML。

## Expected behavior

客户端请求因 deadline/cancel 结束后，服务端应终止尚未完成的 DML，或至少不应向客户端报告取消后再异步提交该次写入。取消后目标表应保持 0 行。

## Stability and controls

- prepared 版本：CN1 3/3、CN2 3/3 均复现；每次均从 0 行延迟变为 2,000,000 行。
- 直接 SQL 版本：CN1 3/3、CN2 3/3 均复现，证明不是 prepare 专属。
- 正常对照：使用 30 秒 deadline 的相同 prepared INSERT 在两个 CN 上均成功提交 2,000,000 行。
- 原子性检查：取消后并非部分行，而是完整提交，属于“错误返回与最终写入状态不一致”。

## Evidence

双 CN 重复运行的探针输出均为：

```text
initial rows after cancellation=0
panic: canceled insert became visible after client returned, rows=2000000
```

## Code analysis

现有回归 `issue_25599_proxy_disconnect_cancel.py` 已覆盖“被锁阻塞的 UPDATE 在客户端断连后不提交”。本问题是已开始执行、服务器端生成数据的长 DML：客户端 deadline 返回后执行仍持续到提交完成，说明取消信号/连接关闭没有在该执行路径中及时中止事务。

## Regression coverage

当前产品行为错误，不能录制为通过的 motr 基线。修复后建议加入带客户端 deadline 的场景测试：断言取消返回后多次轮询目标表始终为 0，并验证新连接可继续执行正常 prepared DML。