v0.9.6 — self-healing browser profile lock for Windows

Fixed

• Windows sessions no longer get permanently locked out of the saved browser profile. The persistent-profile lock now carries a heartbeat lease: the owning worker refreshes it every 15 s, and a lock whose lease has been stale for 60 s is reclaimed even when its recorded pid appears alive. Previously, a hard-killed worker (on Windows, TerminateProcess skips shutdown) left a lock whose pid was quickly recycled by an unrelated live process, so every new session was forced into an ephemeral profile without saved logins with no way to recover. Locks written by ≤0.9.5 keep the old pid-only semantics, so a live old-version holder is never robbed.
• EPERM creating the lock no longer aborts the launch. Sandboxes that block writes outside the workspace (reported on Windows) now degrade gracefully: BetterWright continues on the persistent profile without the advisory lock — Chromium's own profile singleton remains the final authority against true concurrent use.
• Windows EPERM/EBUSY during stale-lock cleanup (open handles, antivirus) now falls back to an ephemeral profile with an actionable warning instead of crashing.
• The occupied-profile warning now tells the agent which pid holds the profile, how to reclaim it, and that a crashed process's lock expires on its own within about a minute.
• Releasing the lock verifies ownership by token, so a worker never deletes a lock another process has since taken over.

Internals

• Lock logic extracted to src/profile-lock.mjs with a dedicated unit suite (tests/node/profile-lock.test.mjs), including the pid-reuse reclaim case.
• Deflaked the worker-exit credential recovery test that intermittently timed out or hung CI.