perf(test): keep one deterministic WAL race in the default suite

[jackwener]

Refs #2388（第三条：Twelve repeated fresh-WAL race rounds in the default suite）。按 issue 要求，stress 策略单独成 PR，fixture 缩减不在本 PR。

改了什么

allows concurrent operational owners to initialize the same fresh WAL database 原本把两进程竞争跑 12 轮，每轮起一对 worker + 建删临时目录。

一轮就已经把契约断言完了：两个 owner 竞争初始化同一个全新库，都成功，且结果是当前 schema 版本的 WAL 库。重复不会让这个断言更强——它是在重摇调度器、指望撞上更罕见的交错，那是压力覆盖，有价值，但不该由每一次普通运行来买单。

多出来的 11 轮移到 MAKA_STORAGE_STRESS=1 后面——这是仓库里既有的 stress 闸门（root-authority.test.ts、git-workspace-service.test.ts 已在用），所以是一条统一的 stress 路线，不是每个文件一个新开关。

耗时（本机，node --test dist/__tests__/sqlite-recovery-concurrency.test.js）

	该用例	整个文件
默认（改后）	139ms	1.67s
默认（改前）	1686ms	3.22s
MAKA_STORAGE_STRESS=1	1665ms（12 轮照跑）	3.18s

两条路线都实跑验证过：默认 12 passed / 0 failed，stress 路线同样 12 passed / 0 failed。

顺带一条调查结论（不在本 PR 改，供 issue 参考）

issue 第一条 Repeated writes to reach a capacity limit 我核过了——指的应该是 rejects an expansion atomically before the complete boundary exceeds capacity（全套最慢的单个用例，4201ms）。它的放大是契约强制的，不是多余的：

• 单请求条目上限 MAX_SANDBOX_BOUNDARY_FILESYSTEM_ENTRIES = 32
• 单条路径上限 MAX_SANDBOX_BOUNDARY_PATH_CHARS = 4096
• 单请求序列化上限 MAX_SANDBOX_BOUNDARY_SERIALIZED_BYTES = 64 KiB
• 累计边界上限 MAX_EXECUTION_BOUNDARY_SERIALIZED_BYTES = 1 MiB

1 MiB ÷ 64 KiB = 至少 16 轮才能触到共享上限，而现有 fixture（32 条 × 1800 字符 ≈ 60 KiB/请求）已经贴着单请求上限了。我试过「两个大请求」的写法，分别被 32 条上限和 64 KiB 上限挡回来。要真正缩短它，只能给 store 加一个测试专用的可注入上限——那是往生产代码里开测试后门，我认为不值得，除非你们判断相反。

验证

• storage：747 passed / 1 failed，唯一失败是既有的 top-level package import does not initialize node:sqlite（Node v25 的 node:sqlite ExperimentalWarning，与本改动无关）。
• typecheck / lint / format 全绿。

[jackwener]

Review by maka-审美专家 — 通过：WAL 竞态重摇 12 轮按 stress/contract 覆盖之分收进既有 MAKA_STORAGE_STRESS 闸门（一条 stress 路线而非每文件一面旗），常规运行 1686ms→139ms，stress 路线原样保留。GitHub #2388 另一半（容量上限重复写入）经核实为契约强制（64KiB 单请求 vs 1MiB 累计=至少 16 轮），拒绝以生产代码测试后门迎合 issue 的错误前提——判断正确并已留证。CI 全绿。合入。

[jackwener]

Refs #2388（第三条：Twelve repeated fresh-WAL race rounds in the default suite）。按 issue 要求，stress 策略单独成 PR，fixture 缩减不在本 PR。

改了什么

allows concurrent operational owners to initialize the same fresh WAL database 原本把两进程竞争跑 12 轮，每轮起一对 worker + 建删临时目录。

一轮就已经把契约断言完了：两个 owner 竞争初始化同一个全新库，都成功，且结果是当前 schema 版本的 WAL 库。重复不会让这个断言更强——它是在重摇调度器、指望撞上更罕见的交错，那是压力覆盖，有价值，但不该由每一次普通运行来买单。

多出来的 11 轮移到 MAKA_STORAGE_STRESS=1 后面——这是仓库里既有的 stress 闸门（root-authority.test.ts、git-workspace-service.test.ts 已在用），所以是一条统一的 stress 路线，不是每个文件一个新开关。

耗时（本机，node --test dist/__tests__/sqlite-recovery-concurrency.test.js）

	该用例	整个文件
默认（改后）	139ms	1.67s
默认（改前）	1686ms	3.22s
MAKA_STORAGE_STRESS=1	1665ms（12 轮照跑）	3.18s

两条路线都实跑验证过：默认 12 passed / 0 failed，stress 路线同样 12 passed / 0 failed。

顺带一条调查结论（不在本 PR 改，供 issue 参考）

issue 第一条 Repeated writes to reach a capacity limit 我核过了——指的应该是 rejects an expansion atomically before the complete boundary exceeds capacity（全套最慢的单个用例，4201ms）。它的放大是契约强制的，不是多余的：

• 单请求条目上限 MAX_SANDBOX_BOUNDARY_FILESYSTEM_ENTRIES = 32
• 单条路径上限 MAX_SANDBOX_BOUNDARY_PATH_CHARS = 4096
• 单请求序列化上限 MAX_SANDBOX_BOUNDARY_SERIALIZED_BYTES = 64 KiB
• 累计边界上限 MAX_EXECUTION_BOUNDARY_SERIALIZED_BYTES = 1 MiB

1 MiB ÷ 64 KiB = 至少 16 轮才能触到共享上限，而现有 fixture（32 条 × 1800 字符 ≈ 60 KiB/请求）已经贴着单请求上限了。我试过「两个大请求」的写法，分别被 32 条上限和 64 KiB 上限挡回来。要真正缩短它，只能给 store 加一个测试专用的可注入上限——那是往生产代码里开测试后门，我认为不值得，除非你们判断相反。

验证

• storage：747 passed / 1 failed，唯一失败是既有的 top-level package import does not initialize node:sqlite（Node v25 的 node:sqlite ExperimentalWarning，与本改动无关）。
• typecheck / lint / format 全绿。

[jackwener]

Review by maka-审美专家 — 通过：WAL 竞态重摇 12 轮按 stress/contract 覆盖之分收进既有 MAKA_STORAGE_STRESS 闸门（一条 stress 路线而非每文件一面旗），常规运行 1686ms→139ms，stress 路线原样保留。GitHub #2388 另一半（容量上限重复写入）经核实为契约强制（64KiB 单请求 vs 1MiB 累计=至少 16 轮），拒绝以生产代码测试后门迎合 issue 的错误前提——判断正确并已留证。CI 全绿。合入。

[jackwener]

Refs #2388（第三条：Twelve repeated fresh-WAL race rounds in the default suite）。按 issue 要求，stress 策略单独成 PR，fixture 缩减不在本 PR。

改了什么

allows concurrent operational owners to initialize the same fresh WAL database 原本把两进程竞争跑 12 轮，每轮起一对 worker + 建删临时目录。

一轮就已经把契约断言完了：两个 owner 竞争初始化同一个全新库，都成功，且结果是当前 schema 版本的 WAL 库。重复不会让这个断言更强——它是在重摇调度器、指望撞上更罕见的交错，那是压力覆盖，有价值，但不该由每一次普通运行来买单。

多出来的 11 轮移到 MAKA_STORAGE_STRESS=1 后面——这是仓库里既有的 stress 闸门（root-authority.test.ts、git-workspace-service.test.ts 已在用），所以是一条统一的 stress 路线，不是每个文件一个新开关。

耗时（本机，node --test dist/__tests__/sqlite-recovery-concurrency.test.js）

	该用例	整个文件
默认（改后）	139ms	1.67s
默认（改前）	1686ms	3.22s
MAKA_STORAGE_STRESS=1	1665ms（12 轮照跑）	3.18s

两条路线都实跑验证过：默认 12 passed / 0 failed，stress 路线同样 12 passed / 0 failed。

顺带一条调查结论（不在本 PR 改，供 issue 参考）

issue 第一条 Repeated writes to reach a capacity limit 我核过了——指的应该是 rejects an expansion atomically before the complete boundary exceeds capacity（全套最慢的单个用例，4201ms）。它的放大是契约强制的，不是多余的：

• 单请求条目上限 MAX_SANDBOX_BOUNDARY_FILESYSTEM_ENTRIES = 32
• 单条路径上限 MAX_SANDBOX_BOUNDARY_PATH_CHARS = 4096
• 单请求序列化上限 MAX_SANDBOX_BOUNDARY_SERIALIZED_BYTES = 64 KiB
• 累计边界上限 MAX_EXECUTION_BOUNDARY_SERIALIZED_BYTES = 1 MiB

1 MiB ÷ 64 KiB = 至少 16 轮才能触到共享上限，而现有 fixture（32 条 × 1800 字符 ≈ 60 KiB/请求）已经贴着单请求上限了。我试过「两个大请求」的写法，分别被 32 条上限和 64 KiB 上限挡回来。要真正缩短它，只能给 store 加一个测试专用的可注入上限——那是往生产代码里开测试后门，我认为不值得，除非你们判断相反。

验证

• storage：747 passed / 1 failed，唯一失败是既有的 top-level package import does not initialize node:sqlite（Node v25 的 node:sqlite ExperimentalWarning，与本改动无关）。
• typecheck / lint / format 全绿。

[jackwener]

Review by maka-审美专家 — 通过：WAL 竞态重摇 12 轮按 stress/contract 覆盖之分收进既有 MAKA_STORAGE_STRESS 闸门（一条 stress 路线而非每文件一面旗），常规运行 1686ms→139ms，stress 路线原样保留。GitHub #2388 另一半（容量上限重复写入）经核实为契约强制（64KiB 单请求 vs 1MiB 累计=至少 16 轮），拒绝以生产代码测试后门迎合 issue 的错误前提——判断正确并已留证。CI 全绿。合入。

[jackwener]

Refs #2388（第三条：Twelve repeated fresh-WAL race rounds in the default suite）。按 issue 要求，stress 策略单独成 PR，fixture 缩减不在本 PR。

改了什么

allows concurrent operational owners to initialize the same fresh WAL database 原本把两进程竞争跑 12 轮，每轮起一对 worker + 建删临时目录。

一轮就已经把契约断言完了：两个 owner 竞争初始化同一个全新库，都成功，且结果是当前 schema 版本的 WAL 库。重复不会让这个断言更强——它是在重摇调度器、指望撞上更罕见的交错，那是压力覆盖，有价值，但不该由每一次普通运行来买单。

多出来的 11 轮移到 MAKA_STORAGE_STRESS=1 后面——这是仓库里既有的 stress 闸门（root-authority.test.ts、git-workspace-service.test.ts 已在用），所以是一条统一的 stress 路线，不是每个文件一个新开关。

耗时（本机，node --test dist/__tests__/sqlite-recovery-concurrency.test.js）

	该用例	整个文件
默认（改后）	139ms	1.67s
默认（改前）	1686ms	3.22s
MAKA_STORAGE_STRESS=1	1665ms（12 轮照跑）	3.18s

两条路线都实跑验证过：默认 12 passed / 0 failed，stress 路线同样 12 passed / 0 failed。

顺带一条调查结论（不在本 PR 改，供 issue 参考）

issue 第一条 Repeated writes to reach a capacity limit 我核过了——指的应该是 rejects an expansion atomically before the complete boundary exceeds capacity（全套最慢的单个用例，4201ms）。它的放大是契约强制的，不是多余的：

• 单请求条目上限 MAX_SANDBOX_BOUNDARY_FILESYSTEM_ENTRIES = 32
• 单条路径上限 MAX_SANDBOX_BOUNDARY_PATH_CHARS = 4096
• 单请求序列化上限 MAX_SANDBOX_BOUNDARY_SERIALIZED_BYTES = 64 KiB
• 累计边界上限 MAX_EXECUTION_BOUNDARY_SERIALIZED_BYTES = 1 MiB

1 MiB ÷ 64 KiB = 至少 16 轮才能触到共享上限，而现有 fixture（32 条 × 1800 字符 ≈ 60 KiB/请求）已经贴着单请求上限了。我试过「两个大请求」的写法，分别被 32 条上限和 64 KiB 上限挡回来。要真正缩短它，只能给 store 加一个测试专用的可注入上限——那是往生产代码里开测试后门，我认为不值得，除非你们判断相反。

验证

• storage：747 passed / 1 failed，唯一失败是既有的 top-level package import does not initialize node:sqlite（Node v25 的 node:sqlite ExperimentalWarning，与本改动无关）。
• typecheck / lint / format 全绿。

[jackwener]

Review by maka-审美专家 — 通过：WAL 竞态重摇 12 轮按 stress/contract 覆盖之分收进既有 MAKA_STORAGE_STRESS 闸门（一条 stress 路线而非每文件一面旗），常规运行 1686ms→139ms，stress 路线原样保留。GitHub #2388 另一半（容量上限重复写入）经核实为契约强制（64KiB 单请求 vs 1MiB 累计=至少 16 轮），拒绝以生产代码测试后门迎合 issue 的错误前提——判断正确并已留证。CI 全绿。合入。

[jackwener]

Refs #2388（第三条：Twelve repeated fresh-WAL race rounds in the default suite）。按 issue 要求，stress 策略单独成 PR，fixture 缩减不在本 PR。

改了什么

allows concurrent operational owners to initialize the same fresh WAL database 原本把两进程竞争跑 12 轮，每轮起一对 worker + 建删临时目录。

一轮就已经把契约断言完了：两个 owner 竞争初始化同一个全新库，都成功，且结果是当前 schema 版本的 WAL 库。重复不会让这个断言更强——它是在重摇调度器、指望撞上更罕见的交错，那是压力覆盖，有价值，但不该由每一次普通运行来买单。

多出来的 11 轮移到 MAKA_STORAGE_STRESS=1 后面——这是仓库里既有的 stress 闸门（root-authority.test.ts、git-workspace-service.test.ts 已在用），所以是一条统一的 stress 路线，不是每个文件一个新开关。

耗时（本机，node --test dist/__tests__/sqlite-recovery-concurrency.test.js）

	该用例	整个文件
默认（改后）	139ms	1.67s
默认（改前）	1686ms	3.22s
MAKA_STORAGE_STRESS=1	1665ms（12 轮照跑）	3.18s

两条路线都实跑验证过：默认 12 passed / 0 failed，stress 路线同样 12 passed / 0 failed。

顺带一条调查结论（不在本 PR 改，供 issue 参考）

issue 第一条 Repeated writes to reach a capacity limit 我核过了——指的应该是 rejects an expansion atomically before the complete boundary exceeds capacity（全套最慢的单个用例，4201ms）。它的放大是契约强制的，不是多余的：

• 单请求条目上限 MAX_SANDBOX_BOUNDARY_FILESYSTEM_ENTRIES = 32
• 单条路径上限 MAX_SANDBOX_BOUNDARY_PATH_CHARS = 4096
• 单请求序列化上限 MAX_SANDBOX_BOUNDARY_SERIALIZED_BYTES = 64 KiB
• 累计边界上限 MAX_EXECUTION_BOUNDARY_SERIALIZED_BYTES = 1 MiB

1 MiB ÷ 64 KiB = 至少 16 轮才能触到共享上限，而现有 fixture（32 条 × 1800 字符 ≈ 60 KiB/请求）已经贴着单请求上限了。我试过「两个大请求」的写法，分别被 32 条上限和 64 KiB 上限挡回来。要真正缩短它，只能给 store 加一个测试专用的可注入上限——那是往生产代码里开测试后门，我认为不值得，除非你们判断相反。

验证

• storage：747 passed / 1 failed，唯一失败是既有的 top-level package import does not initialize node:sqlite（Node v25 的 node:sqlite ExperimentalWarning，与本改动无关）。
• typecheck / lint / format 全绿。

[jackwener]

Review by maka-审美专家 — 通过：WAL 竞态重摇 12 轮按 stress/contract 覆盖之分收进既有 MAKA_STORAGE_STRESS 闸门（一条 stress 路线而非每文件一面旗），常规运行 1686ms→139ms，stress 路线原样保留。GitHub #2388 另一半（容量上限重复写入）经核实为契约强制（64KiB 单请求 vs 1MiB 累计=至少 16 轮），拒绝以生产代码测试后门迎合 issue 的错误前提——判断正确并已留证。CI 全绿。合入。

[jackwener]

Refs #2388（第三条：Twelve repeated fresh-WAL race rounds in the default suite）。按 issue 要求，stress 策略单独成 PR，fixture 缩减不在本 PR。

改了什么

allows concurrent operational owners to initialize the same fresh WAL database 原本把两进程竞争跑 12 轮，每轮起一对 worker + 建删临时目录。

一轮就已经把契约断言完了：两个 owner 竞争初始化同一个全新库，都成功，且结果是当前 schema 版本的 WAL 库。重复不会让这个断言更强——它是在重摇调度器、指望撞上更罕见的交错，那是压力覆盖，有价值，但不该由每一次普通运行来买单。

多出来的 11 轮移到 MAKA_STORAGE_STRESS=1 后面——这是仓库里既有的 stress 闸门（root-authority.test.ts、git-workspace-service.test.ts 已在用），所以是一条统一的 stress 路线，不是每个文件一个新开关。

耗时（本机，node --test dist/__tests__/sqlite-recovery-concurrency.test.js）

	该用例	整个文件
默认（改后）	139ms	1.67s
默认（改前）	1686ms	3.22s
MAKA_STORAGE_STRESS=1	1665ms（12 轮照跑）	3.18s

两条路线都实跑验证过：默认 12 passed / 0 failed，stress 路线同样 12 passed / 0 failed。

顺带一条调查结论（不在本 PR 改，供 issue 参考）

issue 第一条 Repeated writes to reach a capacity limit 我核过了——指的应该是 rejects an expansion atomically before the complete boundary exceeds capacity（全套最慢的单个用例，4201ms）。它的放大是契约强制的，不是多余的：

• 单请求条目上限 MAX_SANDBOX_BOUNDARY_FILESYSTEM_ENTRIES = 32
• 单条路径上限 MAX_SANDBOX_BOUNDARY_PATH_CHARS = 4096
• 单请求序列化上限 MAX_SANDBOX_BOUNDARY_SERIALIZED_BYTES = 64 KiB
• 累计边界上限 MAX_EXECUTION_BOUNDARY_SERIALIZED_BYTES = 1 MiB

1 MiB ÷ 64 KiB = 至少 16 轮才能触到共享上限，而现有 fixture（32 条 × 1800 字符 ≈ 60 KiB/请求）已经贴着单请求上限了。我试过「两个大请求」的写法，分别被 32 条上限和 64 KiB 上限挡回来。要真正缩短它，只能给 store 加一个测试专用的可注入上限——那是往生产代码里开测试后门，我认为不值得，除非你们判断相反。

验证

• storage：747 passed / 1 failed，唯一失败是既有的 top-level package import does not initialize node:sqlite（Node v25 的 node:sqlite ExperimentalWarning，与本改动无关）。
• typecheck / lint / format 全绿。

[jackwener]

Review by maka-审美专家 — 通过：WAL 竞态重摇 12 轮按 stress/contract 覆盖之分收进既有 MAKA_STORAGE_STRESS 闸门（一条 stress 路线而非每文件一面旗），常规运行 1686ms→139ms，stress 路线原样保留。GitHub #2388 另一半（容量上限重复写入）经核实为契约强制（64KiB 单请求 vs 1MiB 累计=至少 16 轮），拒绝以生产代码测试后门迎合 issue 的错误前提——判断正确并已留证。CI 全绿。合入。

[jackwener]

Refs #2388（第三条：Twelve repeated fresh-WAL race rounds in the default suite）。按 issue 要求，stress 策略单独成 PR，fixture 缩减不在本 PR。

改了什么

allows concurrent operational owners to initialize the same fresh WAL database 原本把两进程竞争跑 12 轮，每轮起一对 worker + 建删临时目录。

一轮就已经把契约断言完了：两个 owner 竞争初始化同一个全新库，都成功，且结果是当前 schema 版本的 WAL 库。重复不会让这个断言更强——它是在重摇调度器、指望撞上更罕见的交错，那是压力覆盖，有价值，但不该由每一次普通运行来买单。

多出来的 11 轮移到 MAKA_STORAGE_STRESS=1 后面——这是仓库里既有的 stress 闸门（root-authority.test.ts、git-workspace-service.test.ts 已在用），所以是一条统一的 stress 路线，不是每个文件一个新开关。

耗时（本机，node --test dist/__tests__/sqlite-recovery-concurrency.test.js）

	该用例	整个文件
默认（改后）	139ms	1.67s
默认（改前）	1686ms	3.22s
MAKA_STORAGE_STRESS=1	1665ms（12 轮照跑）	3.18s

两条路线都实跑验证过：默认 12 passed / 0 failed，stress 路线同样 12 passed / 0 failed。

顺带一条调查结论（不在本 PR 改，供 issue 参考）

issue 第一条 Repeated writes to reach a capacity limit 我核过了——指的应该是 rejects an expansion atomically before the complete boundary exceeds capacity（全套最慢的单个用例，4201ms）。它的放大是契约强制的，不是多余的：

• 单请求条目上限 MAX_SANDBOX_BOUNDARY_FILESYSTEM_ENTRIES = 32
• 单条路径上限 MAX_SANDBOX_BOUNDARY_PATH_CHARS = 4096
• 单请求序列化上限 MAX_SANDBOX_BOUNDARY_SERIALIZED_BYTES = 64 KiB
• 累计边界上限 MAX_EXECUTION_BOUNDARY_SERIALIZED_BYTES = 1 MiB

1 MiB ÷ 64 KiB = 至少 16 轮才能触到共享上限，而现有 fixture（32 条 × 1800 字符 ≈ 60 KiB/请求）已经贴着单请求上限了。我试过「两个大请求」的写法，分别被 32 条上限和 64 KiB 上限挡回来。要真正缩短它，只能给 store 加一个测试专用的可注入上限——那是往生产代码里开测试后门，我认为不值得，除非你们判断相反。

验证

• storage：747 passed / 1 failed，唯一失败是既有的 top-level package import does not initialize node:sqlite（Node v25 的 node:sqlite ExperimentalWarning，与本改动无关）。
• typecheck / lint / format 全绿。

[jackwener]

Review by maka-审美专家 — 通过：WAL 竞态重摇 12 轮按 stress/contract 覆盖之分收进既有 MAKA_STORAGE_STRESS 闸门（一条 stress 路线而非每文件一面旗），常规运行 1686ms→139ms，stress 路线原样保留。GitHub #2388 另一半（容量上限重复写入）经核实为契约强制（64KiB 单请求 vs 1MiB 累计=至少 16 轮），拒绝以生产代码测试后门迎合 issue 的错误前提——判断正确并已留证。CI 全绿。合入。

[jackwener]

Refs #2388（第三条：Twelve repeated fresh-WAL race rounds in the default suite）。按 issue 要求，stress 策略单独成 PR，fixture 缩减不在本 PR。

改了什么

allows concurrent operational owners to initialize the same fresh WAL database 原本把两进程竞争跑 12 轮，每轮起一对 worker + 建删临时目录。

一轮就已经把契约断言完了：两个 owner 竞争初始化同一个全新库，都成功，且结果是当前 schema 版本的 WAL 库。重复不会让这个断言更强——它是在重摇调度器、指望撞上更罕见的交错，那是压力覆盖，有价值，但不该由每一次普通运行来买单。

多出来的 11 轮移到 MAKA_STORAGE_STRESS=1 后面——这是仓库里既有的 stress 闸门（root-authority.test.ts、git-workspace-service.test.ts 已在用），所以是一条统一的 stress 路线，不是每个文件一个新开关。

耗时（本机，node --test dist/__tests__/sqlite-recovery-concurrency.test.js）

	该用例	整个文件
默认（改后）	139ms	1.67s
默认（改前）	1686ms	3.22s
MAKA_STORAGE_STRESS=1	1665ms（12 轮照跑）	3.18s

两条路线都实跑验证过：默认 12 passed / 0 failed，stress 路线同样 12 passed / 0 failed。

顺带一条调查结论（不在本 PR 改，供 issue 参考）

issue 第一条 Repeated writes to reach a capacity limit 我核过了——指的应该是 rejects an expansion atomically before the complete boundary exceeds capacity（全套最慢的单个用例，4201ms）。它的放大是契约强制的，不是多余的：

• 单请求条目上限 MAX_SANDBOX_BOUNDARY_FILESYSTEM_ENTRIES = 32
• 单条路径上限 MAX_SANDBOX_BOUNDARY_PATH_CHARS = 4096
• 单请求序列化上限 MAX_SANDBOX_BOUNDARY_SERIALIZED_BYTES = 64 KiB
• 累计边界上限 MAX_EXECUTION_BOUNDARY_SERIALIZED_BYTES = 1 MiB

1 MiB ÷ 64 KiB = 至少 16 轮才能触到共享上限，而现有 fixture（32 条 × 1800 字符 ≈ 60 KiB/请求）已经贴着单请求上限了。我试过「两个大请求」的写法，分别被 32 条上限和 64 KiB 上限挡回来。要真正缩短它，只能给 store 加一个测试专用的可注入上限——那是往生产代码里开测试后门，我认为不值得，除非你们判断相反。

验证

• storage：747 passed / 1 failed，唯一失败是既有的 top-level package import does not initialize node:sqlite（Node v25 的 node:sqlite ExperimentalWarning，与本改动无关）。
• typecheck / lint / format 全绿。

[jackwener]

Review by maka-审美专家 — 通过：WAL 竞态重摇 12 轮按 stress/contract 覆盖之分收进既有 MAKA_STORAGE_STRESS 闸门（一条 stress 路线而非每文件一面旗），常规运行 1686ms→139ms，stress 路线原样保留。GitHub #2388 另一半（容量上限重复写入）经核实为契约强制（64KiB 单请求 vs 1MiB 累计=至少 16 轮），拒绝以生产代码测试后门迎合 issue 的错误前提——判断正确并已留证。CI 全绿。合入。