freebsd Xmmap passed the 64-bit off_t as a single uintptr to Syscall6, which
truncates/misaligns it on 32-bit targets, so the returned mapping faulted on
first use (SIGBUS, e.g. the SQLite WAL-index shm) on freebsd/arm. Move freebsd
Xmmap per-arch (freebsd mmap(2) has NO pad, so amd64/arm64 keep Syscall6; arm
uses Syscall9 with a PAD word + split off_t for EABI alignment; 386 uses
Syscall9 with split off_t, no PAD).

Audit of the other 32-bit BSD targets found the same class of bug in mmap (the
only off_t syscall not going through an x/sys/unix wrapper):
  - netbsd/arm: the shared Xmmap passed only the low off_t word (amd64 form);
    now passes offset>>32 as the high word (read on 32-bit, ignored on 64-bit).
  - openbsd/386: the addr!=0 path was an unimplemented panic(); implement it via
    Syscall9(SYS_MMAP=197) with the PAD + split off_t.
netbsd/openbsd mmap(2) carry the `long PAD` on every arch, so a single Syscall9
encoding is correct across arches. All match golang.org/x/sys/unix's per-arch
mmap. ABI-neutral, no re-transpile.

Validated at runtime with this libc: freebsd/386 + freebsd/arm sqlite
TestFcntlPersistWAL (previously SIGBUS) + the WAL/concurrency subset pass;
netbsd/amd64 (the shipping target) unaffected and still green.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>