Windows smoke: TestForkAndChildHoldTheParentTheyAreCreatedFrom/fork failed once, parent not reported open after Fork #1138

Version / branch / commit

main @ 846d30f5 (the PR that hit it, #1137, is 846d30f5 plus two commits that only touch internal/acp).

OS and environment

GitHub Actions windows-latest, job Smoke (windows-latest), step "Test (Fast Non-Race)".

Steps to reproduce

Not reproduced locally (I only have Linux). It failed once in CI:

• Run: https://github.com/Twigpine/zero/actions/runs/38612762608
• Job: https://github.com/Twigpine/zero/actions/runs/38612762608/job/116020047671

Expected behavior

TestForkAndChildHoldTheParentTheyAreCreatedFrom passes for every case. After Store.Fork succeeds, a Prune dry run in the same process reports the parent as open.

Actual behavior

--- FAIL: TestForkAndChildHoldTheParentTheyAreCreatedFrom (0.34s)
    --- FAIL: TestForkAndChildHoldTheParentTheyAreCreatedFrom/fork (0.09s)
        prune_test.go:415: parent kept for "", want "open in another Zero process": the fork's process holds it

Only the fork case is reported as failed in that run.

Why this looks like a flake rather than a regression in that PR

• fix(acp): persist token usage events for ACP sessions #1137 does not touch internal/sessions; the package is identical to main at 846d30f5.
• Smoke (windows-latest) passed on main for 846d30f5: https://github.com/Twigpine/zero/actions/runs/38581230002
• The Windows run of this test was enabled by test(sessions): run the session lock test on Windows and add a cross-process one #1115, on top of the prune lease from feat(sessions): add zero sessions prune, which never removes a session another process has open #1089.

What I did not establish

This is a single occurrence, so I cannot say whether it is a timing race or an ordering that depends on the runner. I do not have a fix to propose. The question is whether the lease taken by Store.Fork is guaranteed to be visible to the following Prune dry run on Windows.