fix(storage): serialize root marker repair on Windows

[liugddx]

Summary

• serialize root marker identity repair with the stable Artifact writer bootstrap lock
• revalidate root identity and marker state before atomic marker publication
• reject non-file interactive owner lock artifacts consistently across platforms
• cover concurrent repair, writer-lock coordination, and invalid owner-lock artifacts

Root cause

Windows cannot reliably reread or atomically replace the marker while the marker file itself is exclusively locked. Reads can fail with EBUSY, and replacement can fail with EPERM. A stable external lock keyed by the real root identity provides serialization without locking the file being replaced.

Validation

• root-authority test file, three consecutive runs: 24 pass / 0 fail / 7 skip
• root-authority + marker-file + artifact-writer-lock: 38 pass / 0 fail / 10 skip
• npm run build
• npm run typecheck
• Biome format and lint checks
• git diff --check
• full Storage suite: 692 pass / 9 fail / 47 skip; no failures in the root-authority, marker, or artifact-writer groups

The remaining full-suite failures are existing Windows/environment backlog and are not presented as green by this PR.

Relates to #2142.

[jackwener]

Adversarial review — approve

Root cause fix is sound. Marker identity repair no longer locks the marker inode itself (Windows EBUSY/EPERM). It serializes on the identity-keyed Artifact bootstrap lock — same path artifact writers use — then revalidates root identity + marker before publishMarkerFile(replace).

Checked

• Bootstrap lock path = sha256(dev:ino) under private control namespace; shared with withArtifactWriterLock so writer + repair cannot race
• In-process gate + OS exclusive lock; O_NOFOLLOW + stable file/ino revalidation
• Concurrent repairs: second fails closed after first mutates marker (1 fulfilled / 1 rejected)
• Owner lock: pre-check rejects non-file at path with invalid_lock_artifact (clearer than opaque lock_failed)
• Initial marker create still uses publication: 'create' without exclusive path — correct (no existing marker to lock)
• Local root-authority suite: 29 pass / 0 fail / 3 skip

No blocking issues.