refactor: one file lock for seven packages, not fourteen

[dinstein]

Seven packages hand-carried a flock_unix.go / flock_windows.go / flock_stub.go triplet. The
Windows halves were already one implementation in internal/platform and byte-for-byte identical;
the Unix halves were seven hand-written copies and had drifted — internal/secrets retried
EINTR around its non-blocking lock, internal/oauthflow's same-purpose function did not (so a
signal delivered mid-syscall reported the offline refresh path as broken rather than retryable), and
internal/ratelimit was a third variant. The comments still described the copies as structurally
identical.

• 1. internal/platform gains the Unix half of the seam — filelock_unix.go answers
  LockFile / TryLockFile / UnlockFile / IsLockBusy with flock(2) and one EINTR
  policy (retry, below every entry point). filelock_other.go narrows to the platforms with
  neither implementation. syscall only: the package is depguard-locked to $gostd.
  New tests exercise exclusion, the blocking wait and the busy predicate — Unix is the half that
  can actually be executed, and the Windows branch has never had a machine to run on.
• 2. The seven packages collapse to one flock.go each (tagged darwin || linux || windows,
  four lines over internal/platform) plus their existing flock_stub.go. Blocking-versus-
  polling preserved per caller: calllog and ratelimit wait in the kernel, the other five poll
  a non-blocking attempt so they can honour a context. Stale prose removed with it —
  oauthflow cited internal/integrity (retired) and promised Windows "in M2" (shipped), and
  docs/windows.md counted six packages where seven take a lock.
• 3. test/buildrules/flockparity_test.go moves with the syscalls: it demanded a
  flock_windows.go beside every flock_unix.go; it now demands every flock.go reach
  internal/platform and fails any package outside internal/platform that calls
  syscall.Flock or LockFileEx itself. That second claim is the drift the old check could not
  see.

The poll ladder: read, not hoisted

registry/lock.go, httpbridge/fileio.go, skills/lock.go — and, not in the original finding,
secrets/vaultlock.go and oauthflow/refresh.go — carry five near-identical
open / non-blocking-attempt / poll / deadline ladders. They are not hoisted here, and the reason is
that hoisting the wait loop is not a smaller change than it looks:

• The moment platform owns the loop, it also owns the non-blocking attempt and the busy predicate,
  so each package's flockExclusiveNB and isWouldBlock become unreachable and the whole per-package
  lock seam — flock.go, flock_stub.go, and the three packages' crossProcessLockSupported
  fail-closed prose — dissolves into internal/platform with it. That is 21 files and four
  documented failure directions, on top of this branch's 34.
• What would not move is what actually differs: each package's own fileLock type and
  LockTimeoutError (no store may import another's error model, and test/buildrules pins each
  sentinel into the CLI's exit-7 parity table). Every call site would keep an error-mapping switch.

So it deserves its own branch, judged on its own. Two things found while reading them, recorded here
rather than fixed: oauthflow polls with a timeout but returns plain fmt.Errorf, so lock contention
there reaches the CLI as exit 1 while the identical contention in four other stores exits 7 —
and locktimeoutregistry_test.go's comment claimed oauthflow "tries once", which it does not. The
comment is corrected in this branch; the exit-code asymmetry is not.

Verification

make fmt, make ci, and make cross-windows — the last because this branch touches the
_windows.go files and cross-compilation is the only Windows gate that exists.