fix(hosted): persist redirect ledger before lockfile writes - #187

The hosted write path wrote every rewritten lockfile with a plain
fs::write and only afterwards persisted the redirect ledger — the file
that records each entry's pre-redirect resolved/integrity originals,
the only revert data. A mid-loop write failure (read-only path, disk
full, Rush multi-lock repos) therefore exited with some locks already
redirected and their originals never persisted; a re-run could not
recapture them because an already-redirected entry produces no new
edit. The originals were permanently lost.

Reorder and harden the write path:

- Persist the ledger (merged with any existing one) BEFORE mutating
  any lockfile, so every planned edit's original is durable first. A
  recorded edit whose lockfile write then fails is harmless — revert
  would restore bytes the file already has — and a retried run's
  re-planned edits are deduplicated instead of appended.
- Write lockfiles and the ledger with the vendored backend's atomic
  stage+fsync+rename writer (mode-preserving), so a crash mid-write
  can no longer leave a torn lockfile; a ledger failure now leaves the
  project byte-untouched.
- Fail closed on an existing-but-corrupt redirect-state.json (e.g. an
  unresolved merge conflict): the run refuses before touching any
  lockfile instead of silently replacing the ledger and discarding
  the recorded originals (new load_redirect_state_strict; read-only
  consumers keep the lenient loader).
- Percent-decode the version in parse_purl_simple like the name, so a
  canonical encoded purl version (npm 1.2.3%2Bbuild) matches the
  decoded form lockfiles store instead of silently redirecting
  nothing.

Regression tests: mid-run partial write failure keeps the ledger's
originals and leaves the failed lock byte-identical; a corrupt ledger
is refused with the project untouched; an unwritable ledger now fails
before (not after) the lockfile rewrite; strict-loader unit tests; and
purl version decoding.

Co-authored-by: Claude Fable 5 <noreply@anthropic.com>

Reconciles with #192 (fix/redirect-ledger-atomicity), which already
landed the ledger-before-lockfiles ordering, the atomic ledger write
(save_redirect_state), and the fail-closed corrupt-ledger load with
.corrupt quarantine. Kept all of main's #192 machinery and re-expressed
this PR's remaining value on top of it:

- Lockfile writes go through atomic_write_bytes_preserving_mode
  (main still used bare fs::write for the rewrite.files loop).
- FileEdit derives PartialEq and the ledger merge skips byte-identical
  re-planned edits from a retried partial failure.
- parse_purl_simple percent-decodes the version like the name.
- New test partial_lockfile_write_failure_persists_ledger_originals
  (mid-run multi-lock failure: originals durable, failed lock
  byte-untouched).
- Leg 3 of the write-failure envelope test obstructs the lock's
  DIRECTORY (unix-gated): with atomic writes a read-only lock FILE is
  replaced mode-preserved instead of failing.

Dropped as subsumed by #192: load_redirect_state_strict (superseded by
CorruptRedirectState), this branch's own atomic ledger write and
ledger-first ordering, and corrupt_ledger_is_refused_not_replaced
(superseded by corrupt_ledger_fails_closed_and_preserves_the_bytes,
whose quarantine semantics intentionally MOVE the corrupt file).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>