Phase 2c: rename, wired through the VFS to runtime.fs

Completes the Phase 2 FAT mutation set (truncate, mkdir, unlink, rename).

- engine: rename(dir, old_name, new_name) rewrites an existing entry's 8.3 name in
  place within the same directory. Refuses a missing source, a non-8.3 target, or a
  name that already exists; drops any long-name entries on the old file (it takes
  its new 8.3 name), LFN-aware like removeFile. Cross-directory and long-name-
  preserving rename are noted limitations. Host-tested (rename keeps contents;
  collision, non-8.3, and missing-source are refused).
- vfs protocol: a `rename` operation whose payload is old-path, a 0x00 separator,
  then new-path.
- VFS router: a forwardRename helper + a `.rename` case that requires both paths
  under the same mount (cross-filesystem rename is refused) and forwards the
  mount-relative old+new.
- fat server: a `.rename` handler that requires the same parent directory and calls
  engine.rename.
- runtime.fs: rename(old_path, new_path).
- fat-test now renames the file it created (before removing it) and asserts the old
  name is gone, behind a new `fat-rename` QEMU case.

Verified: zig build, zig build test (the engine rename unit test), zig build
check-fat-image, and a sequential QEMU sweep — fat-mount, fat-mutations, fat-rename,
vfs, vfs-client-death, log-flush, orderly-shutdown, initial-ramdisk, smoke — green.

docs/zig-self-hosting.md

@@ -251,13 +251,15 @@ Because `std.fs`/`std.Io` have no per-OS branches, finishing this in `runtime.os
 lights up the whole file tower for the compiler at once. Environment can stay an empty
 map until the kernel populates a non-empty `envp`.
 
-**Status (Phase 2a–2b landed):** `truncate` (O_TRUNC end to end, closing the boot-log
-stale-tail bug), `mkdir`, and `unlink` are all wired through the FAT engine, the VFS
-protocol + router, and `runtime.fs` (`makeDirectory`/`remove`) — host-tested and
-QEMU-tested (the `fat-mutations` case creates a directory, writes+reads a file in it,
-then removes it through the mount). `removeFile` is LFN-aware. Still to do: `rename`
-(engine + wiring), and then the richer `stat` — mtime/mode — which needs **wall-clock**
-(a kernel RTC read), the natural next kernel-side step.
+**Status (Phase 2a–2c landed):** `truncate` (O_TRUNC, closing the boot-log stale-tail
+bug), `mkdir`, `unlink`, and `rename` are all wired through the FAT engine, the VFS
+protocol + router, and `runtime.fs` (`makeDirectory` / `remove` / `rename`) —
+host-tested and QEMU-tested (the `fat-mutations` + `fat-rename` cases make a directory,
+write+read a file in it, rename it, then remove it through the mount). `removeFile` and
+`rename` are LFN-aware; `rename` is same-directory + 8.3 (cross-directory and
+long-name-preserving rename are noted limitations). **Remaining Phase 2:** the richer
+`stat` — mtime/mode — which needs **wall-clock** (a kernel RTC read behind a syscall,
+consistent with time being a kernel concern), the natural next kernel-side step.
 
 ### Phase 3 — Single-threaded, self-linked compiler bring-up