fix(import): buffered creates break same-file lookup references

[yinlianghui]

Baseline and relation to #2678/#2680

• Verified at 98874656ffc50ce1531af52346228ffcdda73fba.
• Regression introduced by perf(seed,import): route bulk writes through the engine's batch insert path #2680 (21420d9f82e): pre-PR import created each row inline; perf(seed,import): route bulk writes through the engine's batch insert path #2680 buffers creates until a progress/batch flush. import-runner.ts is unchanged after merge.
• No exact duplicate issue was found.

Minimal reproduction

Import into a real SQL self-referencing object:

Alice
Bob.manager = Alice
Carol.manager = Alice

Compare the same protocol with and without createManyData.

Expected / actual

• Expected: prior rows in the same file are visible to later lookup resolution; both paths import 3/3 with the same semantics.
• Actual: bulk path resolves Bob/Carol before Alice is flushed, caches the first not-found, and creates only Alice (1 created / 2 reference errors). Sequential compatibility path creates 3/3.

Reproduced 2/2 in the integration harness and again through the real showcase HTTP API (root succeeds, child reference fails).

Impact

Enabling the #2680 bulk capability changes import semantics for hierarchical and same-file relational data, causing deterministic row loss/errors in previously valid import order.

Evidence and exclusions

• Source boundary: packages/rest/src/import-runner.ts reference coercion/cache occurs before pendingCreates flush.
• Ordinary lookup to pre-existing database rows passes.
• This does not request batching lookup reads; it requires preserving pre-perf(seed,import): route bulk writes through the engine's batch insert path #2680 same-file visibility semantics.

Required regression tests

• Real-protocol same-file self-reference with bulk capability imports 3/3.
• Result order, cache behavior, batching, and no-bulk compatibility remain covered.
• Include progress-boundary cases so correctness does not depend on accidental flush cadence.

[yinlianghui]

UI 稳定复现证据（#2678 follow-up）

固定环境：framework 98874656ffc50ce1531af52346228ffcdda73fba；ObjectUI 80901aad44ff3beeaf7882ec3367da934325b2f2。

稳定复现规则：

1. 准备一个已存在父记录。
2. CSV 第 1 类引用已存在父记录，用于确认 lookup 基础路径正常。
3. CSV 中创建一个全新父记录。
4. 后续行在同一 CSV 中通过 lookup 引用该新父记录。
5. 使用全新的唯一名称重复两轮。

两轮结果均一致：已有父记录可解析、新父记录可创建，但后续行无法引用同文件刚创建的父记录；结果为 2 条创建、1 条跳过，并报告 no showcase_category matches。API/SQLite 同时确认失败子记录未落库。因此复现判定不是“任意 lookup 失败”，而是“仅同文件尚在缓冲区的新父记录不可见”。

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