init-session.ps1: a read-only .active_plan pointer fails the named-plan init and leaves the new plan directory behind

Problem

init-session.ps1 <name> creates the plan directory first and then asks set-active-plan.ps1 to point .planning/.active_plan at it. When the existing pointer file carries the Windows ReadOnly attribute, the verification step accepts it but the replacement step fails, so the new plan directory is left behind and init exits 1.

Scope: named-plan mode on Windows only. The default zero-argument root mode never touches .active_plan and is not affected.

How to reproduce

.\scripts\init-session.ps1 "First"
Set-ItemProperty -LiteralPath .planning\.active_plan -Name IsReadOnly -Value $true
.\scripts\init-session.ps1 "Second"

Observed: Error: could not safely update the active plan pointer at ...\.planning\.active_plan, exit code 1, and .planning\<date>-second\ exists on disk while the pointer still names the first plan.

Cause: Test-SafeActiveFile in skills/planning-with-files/scripts/set-active-plan.ps1 checks that the pointer is a regular, in-project, non-reparse file, but not its ReadOnly attribute. [IO.File]::Replace on a read-only target then throws Access to the path is denied. init-session.ps1 had already run -VerifyRoot (which passed) and New-Item for the plan directory before that call.

The shell twin (init-session.sh with set-active-plan.sh) replaces a read-only pointer without error because mv -f replaces the directory entry.

Suggested fix

Either of these keeps the twins in step:

• Reject a ReadOnly pointer in Test-SafeActiveFile, so -VerifyRoot fails before the plan directory is created and the error names the attribute.
• Clear the ReadOnly attribute on the target immediately before [IO.File]::Replace, matching the shell twin's behaviour.

Whichever is chosen, init-session.ps1 should not leave the freshly created plan directory behind when the pointer update fails. A regression test in tests/ that sets the attribute and asserts both the exit code and the absence of the orphaned directory would close this.

Origin

Found by the v3.19.0 release review (PRs #247, #248, #249). Tracked as item 1 of #250 before that issue was split into one issue per item.