The layer journey's post-move assertion sweeps all of ~/local out of the record; on Windows a kept w.ps1 is rightly there, and the two Windows scenario jobs are red on develop #941

Epic: WritDeployment · Feature: #762 The writ lifecycle surface · found by PR #940's CI (schedule #916, PR A), 2026-09-24

The failure

scenario (windows-amd64) and scenario (windows-arm64) on PR #940, in TestWritLayerJourneyScenario_Part3_Move/by-path:

scenario_layer_journey_test.go:1195: the record still mentions an old ~/local target after the redeploy replaced it (#922):
  C:\Users\runneradmin\AppData\Local\Temp\...\home\local\bin\w.ps1 is linked

The Unix legs passed, quality-gate passed, and the pull request merged; develop is red on the two Windows
scenario jobs.

Mechanism

Lane 1 (#922) rewrote step 3.4/3.5 of the layer journey: after the redeploy replaces the record, the record says
nothing about the replaced lifetime's targets. The assertion I wrote sweeps every target under ~/local out of
the record. On Windows the fixture's later commit still deploys common.Windows/local/bin/w.ps1 under ~/local, so
that link is rightly in the new record, and the sweep reads a correct record as a stale one. The Unix fixtures keep
nothing under ~/local after the move, which is why only Windows failed.

The fix

Assert over the targets the move actually took away -- the expected set the step computes from the fixture diff,
the paths that dangled -- and not over a directory: none of those may appear in the record in any state. The
missing == 0 assertion stays.

Acceptance

• the two Windows scenario jobs are green on develop
• the assertion names the moved-away targets, not ~/local