NetBSD's Xabort was a panic(todo()) stub, so C abort(3) terminated the process
the wrong way: the Go runtime intercepts a delivered SIGABRT and exits with
status 2 instead of dying by signal. SQLite's crash tests (writecrash.test) fork
a child that abort()s and require it to be killed by SIGABRT; the stub made the
child "exit abnormally" instead, failing writecrash-1.1.1 on netbsd/amd64.

x/sys/unix exposes no high-level Sigaction on netbsd and Xsigaction is
unimplemented here, so reset SIGABRT to SIG_DFL via the raw
__sigaction_sigtramp(2) syscall (an all-zero struct sigaction = SIG_DFL;
trampoline/version are unused for SIG_DFL), then raise SIGABRT so the kernel
terminates the process by signal. ABI-preserving (Xabort signature unchanged).

Validated on NetBSD 10.1/amd64: a child calling libc.Xabort is now killed by
signal SIGABRT (exit 134), the behavior writecrash-1.1.1 expects.

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

The first Xabort fix used a process-directed kill(2), which delivers SIGABRT
asynchronously; the calling thread could race ahead to the fallback panic and
exit(2) before the signal landed — observed as a rare SQLite crash-test failure
(writecrash-1.95.1) after ~94 crash iterations had already passed.

Deliver SIGABRT synchronously and thread-directed via _lwp_kill(_lwp_self())
(the primitive the Go runtime's raise() uses), after unblocking SIGABRT on the
calling thread (__sigprocmask14 SIG_UNBLOCK) so a blocked mask cannot defeat it.
The process-directed kill(2) and panic remain as unreachable fallbacks.

Validated on NetBSD 10.1/amd64: 20/20 child aborts die by signal SIGABRT, both
on the happy path and with SIGABRT pre-blocked on the calling thread.

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

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>