feat(booter): POSIX/P2P kernel roadmap — sockets, disk.os, VFS, docs

- Bump bareOsCtxApiVersion to 1.46.0 and POSIX profile 1.0.10; sync
  syscalls example, process table, compatibility matrix, CHANGELOGs.
- Socket FD bridge: passive SOCK_DGRAM bind/connect/send path, poll
  readiness; bareOsPosixPoll monotonic timeouts via bare-hrtime.
- disk.os: replication_operator_sketch schema 2; cap-gated
  replication_operator_intent + audit; enrich protomux proc JSON.
- VFS: route /.bare/** to personal drive; optional
  BARE_OS_PERSONAL_VAULT_INDEX_CACHE_MS readdir TTL cache.
- Boot policy: p2pAdmission (peerAllowlistHex, hyperswarmBootstrap) in
  schema + kernel init merge into ctx.env when unset.
- Coreutils/booter getconf: expand _SC_* coverage; shell wait -n under
  BARE_OS_SHELL_POSIX_MODE; seeder multisig verify → security_posture.
- Tests: vfs /.bare routing; test.bare-smoke + test:bare; bench schema 2.
- Docs: syscall-socket-contract, handbook/env/kernel-extensions,
  holepunch drift pretest note, vault threat model multisig section.
- Drop hyperbee from bare-os-booter package.json dependencies (if that
  change is part of this commit).

users-manual/05-home-identity-and-vault.md

@@ -55,6 +55,8 @@ Think in **two layers**:
 1. **Hyperdrive blocks** replicated through Corestore — durable bytes identified by keys and discovery topics, not by a traditional host path.
 2. **VFS paths** — what you see in the shell (**`/home/guest`**, **`/.bare/account`**, **`/mnt/...`**) as the booter merges drives and synthetic mounts.
 
+**`/.bare/**` on the VFS** resolves to the **personal** Hyperdrive (identity, vault blobs, HDMS registry snapshots), not the read-only system image. For very large trees, operators may set **`BARE_OS_PERSONAL_VAULT_INDEX_CACHE_MS`** so **`ls`** / **`readdir`**-heavy tools can reuse directory listings for a short TTL (default: uncached, always consistent with replication). See the [environment appendix](../docs/reference/environment-and-posix-appendix.md).
+
 Guests can write under guest **`HOME`** and read shared system content. **Unlocked** users get a different **`HOME`** subtree and can manipulate HDMS registry entries that survive across sessions. If you are debugging “where did my file go?”, check both **`pwd`** and whether you **logged out** (which clears in-memory keys even when ciphertext remains on disk).
 
 ---