srandomdev() seeds the random number generator from /dev/urandom.
The previous stub panicked with todo(""), breaking any program that
calls it on macOS (e.g. SQLite AFP locking path on network volumes).

Seed the shared randomGen from crypto/rand, matching the existing
pattern used by Xarc4random_buf.

Implement Xsrandomdev for darwin

See merge request !31

Xinitstate built a math/rand.Rand and immediately discarded it, so
initstate(seed, ...) was a silent no-op on the non-musl path
(darwin/*bsd/illumos) while the musl/linux build reseeds via srandom.
Seed the shared randomGen under randomMu instead, matching the
just-added Xsrandomdev and bringing the non-musl path in line with musl.

No API change: signature unchanged, still returns NULL, already in the
capi manifests. setstate stays unsupported because random() is modeled
by a single global generator with no per-call state buffer to switch to.

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

setstate() returned EINVAL, injecting a spurious error into callers
doing the standard initstate/setstate save/restore idiom. random(3) is
modeled by a single global generator with no independent saved stream
to switch to, so treat setstate as a no-op and return the passed
(non-NULL) pointer to signal success instead of failing.

Also remove the orphaned staticRandomData comment whose only user was
the discarded rand.New call removed in the previous commit.

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

wasm2c's --enable-threads output routes every shared-memory load/store
through C11 atomics (the shared memory's data pointer is _Atomic
volatile), including plain f32/f64 access. libc provided the Int/Uint
widths but no float variants, so such a module failed to link with
undefined __atomic_loadFloat32 / __atomic_loadFloat64 /
__atomic_storeFloat32 / __atomic_storeFloat64.

Add the four out-parameter helpers, each delegating to its same-width
integer sibling (an atomic op on the value's bit pattern). wasm has no
atomic-float read-modify-write, so load and store are the complete set.

Verified end-to-end: a shared-memory f32/f64 module translated by
wa2c/wasm2c (--enable-threads) -> ccgo -> Go builds and runs correctly
against this libc.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

The float-atomic round-trip test referenced __ATOMIC_SEQ_CST, a constant
emitted only by the ccgo_linux_*.go generated files. The test has no build
constraint, so it broke the build on every non-linux target (freebsd, netbsd,
openbsd, darwin, windows):

    ./stdatomic_test.go:25:94: undefined: __ATOMIC_SEQ_CST

Define a portable test-local constant instead. The float helpers ignore the
memory order anyway. Verified natively on the freebsd/amd64 builder.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

TestAtomicLoadStoreFloat/Float64 panicked on windows/386:

    panic: unaligned 64-bit atomic operation

The Float64 cell went through atomic.Store64/Load64, which require 8-byte
alignment on 386/arm/32-bit-mips. Natural Go allocation does not provide it
there: unsafe.Alignof(float64) == 4 on 386, so plain locals, make([]float64),
and new(int64) are only 4-byte aligned (verified under GOARCH=386). The earlier
"passing" runs were layout luck.

Allocate the cells in an over-sized byte buffer and align manually to 8 bytes
(also satisfies the 32-bit float case), and assert the alignment in the helper
so a regression fails loudly instead of passing by chance. Verified on
linux/amd64 and natively under GOARCH=386; cross-builds clean on freebsd/386,
windows/386, linux/arm, etc.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Xabort on openbsd was panic(todo("")), so C abort(3) never terminated the
process by a signal. SQLite's crash-recovery tests (writecrash.test and the
crash*.test family) require the child to die BY A SIGNAL so the parent's Tcl
exec reports "child killed: ..."; the stub made it panic ("exited abnormally")
instead, which regressed with the SQLite 3.53.3 upgrade.

A faithful SIGABRT-based abort is unreachable from pure-Go libc on openbsd:
  - libc's own Xsigaction is an unimplemented stub, so SIGABRT's disposition
    cannot be reset to SIG_DFL; the Go runtime therefore always catches a
    delivered SIGABRT, prints a crash traceback, and exits status 2 — again
    "exited abnormally", not "killed".
  - openbsd's pinsyscalls(2) makes the raw sys_sigaction(46)/getthrid(299)/
    thrkill(119) syscalls return ENOSYS through the generic indirect syscall
    path (only libc.so's pinned call sites may issue them; verified: sigaction
    -> errno 78). So the netbsd-style SIG_DFL-reset + thread-directed thrkill
    approach cannot be ported.

Terminate via SIGKILL instead: it cannot be caught, blocked, or ignored, so it
kills the process immediately and unconditionally by signal — no race, no
traceback, no "SIGABRT" string leaking into test output. unix.Kill routes
through libc.so, so unlike the raw syscalls it is not defeated by pinsyscalls.

Fixes openbsd/amd64 and openbsd/arm64 (shared libc_openbsd.go). Validated
against SQLite 3.53.3: writecrash.test 0 errors out of 997 subtests, and the
whole crash*.test/multiplex/quota family green on both arches.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>