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>