fix(import): running async jobs cannot be cancelled on local SQLite

[yinlianghui]

Summary

A running asynchronous CSV import could not be cancelled in the local SQLite showcase environment.

This was found during the UI follow-up for #2678, using framework baseline 98874656ffc50ce1531af52346228ffcdda73fba and the pinned ObjectUI build 80901aad44ff3beeaf7882ec3367da934325b2f2. It is not claimed as a regression introduced by #2680.

Reproduction

1. Start the showcase backend and pinned ObjectUI console.
2. Import a CSV containing 50,000 valid rows.
3. While the import is running and the Cancel control is visible, click Cancel.
4. Wait for the job to finish and inspect import history/backend state.
5. Repeat from a clean run.

Observed in 2/2 runs:

• The UI accepted the cancel action.
• The import history/backend job eventually reported succeeded.
• All 50,000 rows were imported.

Expected

The running job stops at a cancellation checkpoint, retains only the already committed partial progress, and ends with a terminal cancelled state.

Actual

The job completes successfully and imports all rows.

Technical boundary

The current implementation stores cancellation requests in the process-local cancelledImportJobs set and checks it from the worker through shouldCancel. The import runner checks at progress intervals (200 rows), but the synchronous SQLite workload may prevent the cancel HTTP request from being handled in time. Exact event-loop timing should be confirmed with focused instrumentation before choosing a fix.

Existing integration coverage verifies unknown/already-finished cancellation, but does not exercise cancelling a live running job over HTTP with SQLite.

Suggested regression coverage

Add a real HTTP + SQLite integration test that:

• starts a sufficiently long asynchronous import;
• waits until the job is running;
• sends the cancel request;
• verifies the request is observed before completion;
• verifies the final state is cancelled;
• verifies imported rows match the last committed partial progress and do not reach the full input count.

[yinlianghui]

UI + 作业历史稳定复现证据

固定环境：framework 98874656ffc50ce1531af52346228ffcdda73fba；ObjectUI 80901aad44ff3beeaf7882ec3367da934325b2f2；本地 SQLite + 全新 --fresh 后端。

运行期间取消控件可见：

取消动作后，向导显示已取消：

但同一补证栈的历史最终显示 50,000/50,000、成功：

稳定复现与判定规则：

1. 每轮使用 50,000 条名称唯一、校验有效的新记录。
2. 后台任务仍为 running、进度显示 0/50,000 且取消控件唯一可见时点击取消。
3. 不以向导即时文案作为成功判定；等待任务终态。
4. 同时核对 sys_import_job、导入历史和业务表记录数。
5. 使用新的数据前缀重复两轮。

2/2 结果均为作业 succeeded、进度 50,000/50,000、业务表完整新增 50,000 条。取消成功的严格判定应是终态 cancelled 且业务记录数小于完整输入；本次两轮均不满足。

固定 commit 下的完整证据与报告

[yinlianghui]

关联边界：同一次 2/2 端到端复现还暴露了前端误报，已单独记录为 objectstack-ai/objectui#2393。当前 Issue 仅跟踪服务端 running job 未实际停止并最终进入 succeeded/50000/50000；objectui#2393 仅跟踪服务端未确认 cancelled 时，向导仍显示“已取消 / 0 条”。两者共享固定版本、全新本地 SQLite 后端、每轮独立唯一数据前缀和 50,000 条有效记录这些复现前提，但属于不同仓库与修复边界。SQLite 阻塞事件循环仅是待 instrumentation 验证的候选解释，不是已确认根因。