feat(rdd): Windows LockFileEx implementation — real byte-range locks

Replace the no-op Windows lock stub with actual kernel32 LockFileEx /
UnlockFileEx calls via syscall.LazyDLL (zero external dependency).

- LOCKFILE_EXCLUSIVE_LOCK | LOCKFILE_FAIL_IMMEDIATELY for non-blocking
  semantics matching Clipper FLOCK() → .F.
- Same lock region layout as POSIX: header region for FLOCK, record
  offsets for DBRLOCK — compatible across platforms
- Handles returned as syscall.Handle from os.File.Fd()

Note: full Windows cross-compile still blocked by unrelated issues
(mmap in cdx/ntx, termios in debugcli.go). The lock code itself
compiles cleanly with //go:build windows.

Also updates gap-analysis.md to reflect Windows lock status.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

docs/gap-analysis.md

@@ -108,7 +108,11 @@ per-fd, so same-process tests would be meaningless).
 
 ### Limitations
 
-- **Windows**: still a no-op stub. `LockFileEx` wrapper needed (~1 day).
+- **Windows**: real `LockFileEx`/`UnlockFileEx` implementation in
+  `locks_windows.go` using `kernel32.dll` direct syscalls (no external
+  dependency). Note: full Windows cross-compile requires separate fixes
+  for mmap (`hbrdd/cdx`, `hbrdd/ntx`) and termios (`hbrt/debugcli.go`)
+  which are unrelated to locking.
 - **Advisory only**: processes that don't call `FLOCK`/`DBRLOCK` bypass
   protection. Same as Harbour and Clipper — this is expected behavior.
 - **No timeout**: Harbour's `HB_SET_LOCKRETRY` is not honored. Callers