Filesystem CAS for externally-stored fact bytes — the disk half of
PgFactStore, threaded over the injectable runtime/*Deps rather than raw
node:fs, so it runs unchanged under Node, Deno, and a mock runtime.
Large facts (over the embedded threshold) live on disk at the canonical
sharded layout <facts_dir>/<shard>/<rest> — <shard> is the first 2 hex
chars of the blake3 digest, <rest> the remaining 62 — with the fact row
carrying external_url = file:<shard>/<rest> (disk-root-relative). The layout
is single-sourced by fact_disk_path in db/file_fact_url.ts, so the write
path here and the URL minted into the row can't drift. The TS twin of the
Rust fuz_fact disk CAS.
Writes land through <facts_dir>/.tmp/<rand>.tmp, are fsynced, then
renamed into the content-addressed final path. The rename is atomic on
POSIX (a *concurrent reader* observing the path sees either the full content
or nothing), but atomicity is not durability — the fsync before the rename
is what guards against a *host crash* leaving a torn/zero file at a published
CAS path, because the serving path streams the hash-named file without
re-hashing it (server/serve_fact_route.ts). This twins the Rust fuz_fact
§fsync posture: data-sync before the rename; the parent-dir fsync stays
deliberately waived (a lost dirent is regenerable under content addressing).
If the final path already exists the temp is dropped instead of renamed over
— idempotent dedup (same hash → byte-identical content), mirroring the Rust
commit path. .tmp/ is a sibling of <shard>/ under the same facts_dir so
rename is always same-filesystem (no EXDEV).