ci(windows): eliminate hidden failures in the non-blocking baseline

Problem

The Windows baseline currently reports an overall successful workflow while individual continue-on-error steps emit failure annotations. This makes the PR check green without giving us a clean Windows baseline.

PR #2613 exposed the current set in run 31323029613. The latest comparable main run, 31322689039, reproduces the deterministic failures.

Observed failures

1. Windows skip inventory is stale

Both the PR and main report:

Windows test skip inventory is stale; run `npm run windows:inventory:write`

The generated inventory must be refreshed and reviewed against the current tree.

2. Runtime PTY cleanup leaves SQLite locked

Both the PR and main run the two selected PTY tests successfully, then fail suite cleanup:

EBUSY: resource busy or locked, unlink '...\maka-shell-run-...\runtime.sqlite'

The test or production owner still holds the SQLite file when the temporary root is removed. Windows does not permit unlinking an open database.

3. Root-authority initialization race fixture resolves too early

Both the PR and main fail:

rejects replacement before opening the temporary marker
initialization race fixture reported resolved while waiting for marker_open_pending

This is a regression in an area previously tracked as completed by #2438. The fixture must preserve the intended cut on Windows instead of resolving before the marker-open observation.

4. Intermittent SQLite file-lock failures

The latest PR run also observed two failures that did not reproduce in the prior PR run or the compared main run:

EBUSY: resource busy or locked, unlink '...\workspaces\default\memory.sqlite'
EPERM: operation not permitted, open '...\memory.sqlite-shm'

The first occurred during Desktop real-window smoke cleanup. The second occurred in the concurrent Long-term Memory CAS test. Their one-run appearance suggests timing-sensitive ownership or cleanup rather than a deterministic semantic failure, but they still need repeated evidence before being classified as flakes.

Why this matters

The lane is intentionally non-blocking, but a successful outer job currently hides real failing steps. This prevents the baseline from showing whether Windows lifecycle correctness is improving or regressing.

The goal is not to mask Windows file locking with broad retry loops. Every Store, Host, and fixture should release its exact owner before temporary-root cleanup.

Desired outcome

• npm run windows:inventory is clean on the merge tree.
• Runtime PTY tests close the SQLite owner before temporary-root removal.
• The root-authority race fixture reliably reaches marker_open_pending before replacement is evaluated.
• Desktop smoke closes Runtime Host and Memory owners before deleting the fixture root.
• Concurrent Long-term Memory CAS does not race database sidecar permission setup.
• At least three consecutive windows-latest baseline runs complete without failure annotations for these groups.
• The baseline summary makes every failed inner step visible even while the job remains non-blocking.

Suggested work split

1. Refresh the generated Windows skip inventory.
2. Fix deterministic owner/fixture lifecycle failures: Runtime PTY and root authority.
3. Reproduce the Desktop and Long-term Memory file-lock failures under a repeated Windows stress gate.
4. Keep the fixes at the ownership boundary; do not add catch-and-retry cleanup that can hide a live handle.
5. Re-evaluate whether the lane can become blocking after the tracked baseline is clean.

Evidence and context

• Windows roadmap: #2142
• Runtime Host PR: #2613
• Current PR baseline: run 31323029613
• Previous PR baseline: run 31322725976
• Comparable main baseline: run 31322689039
• Earlier root-authority work: #2438
• Earlier inventory refresh: #2434

问题

Windows baseline 当前会在多个 continue-on-error step 产生 failure annotations，但整个 workflow 仍显示成功。因此 PR check 是绿色的，Windows baseline 本身却并不干净。

PR #2613 的 run 31323029613 暴露了当前问题。最新可比较的 main run 31322689039 可以复现其中的确定性失败。

已观察到的失败

1. Windows skip inventory 已过期

PR 与 main 都报告：

Windows test skip inventory is stale; run `npm run windows:inventory:write`

需要根据当前代码树重新生成并审查 inventory。

2. Runtime PTY cleanup 遗留被锁定的 SQLite 文件

PR 与 main 中两个目标 PTY tests 本身都成功，但 suite cleanup 随后失败：

EBUSY: resource busy or locked, unlink '...\maka-shell-run-...\runtime.sqlite'

删除临时 root 时，test 或 production owner 仍持有 SQLite 文件。Windows 不允许 unlink 已打开的数据库。

3. Root-authority initialization race fixture 过早结束

PR 与 main 都失败于：

rejects replacement before opening the temporary marker
initialization race fixture reported resolved while waiting for marker_open_pending

该领域此前在 #2438 中被标记为已完成，因此这是一个回归。Fixture 必须在 Windows 上保留预期的 execution cut，不能在观察到 marker open pending 之前结束。

4. 偶发 SQLite 文件锁失败

最新 PR run 还出现了两个没有在前一轮 PR run 或对照 main run 中复现的问题：

EBUSY: resource busy or locked, unlink '...\workspaces\default\memory.sqlite'
EPERM: operation not permitted, open '...\memory.sqlite-shm'

前者发生在 Desktop real-window smoke cleanup，后者发生在 concurrent Long-term Memory CAS test。它们只出现一次，更像 timing-sensitive ownership 或 cleanup 问题，而不是确定性的语义错误；但在获得重复证据前，也不能直接归类为 flake。

为什么需要处理

该 lane 目前有意保持 non-blocking，但成功的外层 job 会隐藏实际失败的 steps，导致 baseline 无法准确表达 Windows lifecycle correctness 是改善还是回退。

目标不是通过宽泛 retry loop 掩盖 Windows 文件锁。每个 Store、Host 与 fixture 都应在临时 root cleanup 前释放自己的准确 owner。

目标结果

• Merge tree 上的 npm run windows:inventory 保持干净。
• Runtime PTY tests 在删除临时 root 前关闭 SQLite owner。
• Root-authority race fixture 能稳定到达 marker_open_pending，再判断 replacement。
• Desktop smoke 在删除 fixture root 前关闭 Runtime Host 与 Memory owners。
• Concurrent Long-term Memory CAS 不再与 database sidecar permission setup 竞争。
• 至少连续三次 windows-latest baseline 不再出现这些 failure annotations。
• Baseline summary 在 job 仍为 non-blocking 时也明确显示每个失败的 inner step。

建议拆分

1. 刷新生成的 Windows skip inventory。
2. 修复确定性的 owner/fixture lifecycle 问题：Runtime PTY 与 root authority。
3. 在重复 Windows stress gate 下复现 Desktop 与 Long-term Memory 文件锁问题。
4. 在 ownership boundary 修复问题；不要增加可能掩盖 live handle 的 catch-and-retry cleanup。
5. Baseline 清零后，再评估是否将该 lane 改为 blocking。

证据与上下文

• Windows roadmap：#2142
• Runtime Host PR：#2613
• 当前 PR baseline：run 31323029613
• 前一轮 PR baseline：run 31322725976
• 可比较的 main baseline：run 31322689039
• 之前的 root-authority 工作：#2438
• 之前的 inventory refresh：#2434