nx_chacha20_pure.nx

nx_chacha20_pure.nx -- architecture-neutral ChaCha20 (arena-based). Arena-refactor arc piece 1 per docs/NISHI_LANG_FRICTION_CATALOG.md#F5. Parallel to the original nx_chacha20.nx (RV64-pinned via `import "nx_syscalls.nx"` for sys_mmap). This variant takes `*NxArena` for all internal scratch buffers and imports NO syscall layer -- composes cleanly with x86_64-native sockets in one binary, proven by bench/nx_chacha20_pure_x86_64_smoke.nx. Why parallel rather than in-place: existing downstream consumers (nx_chacha20_poly1305, nx_tls13_record, nx_tls13_loopback_test) pass through ~6 RV64+qemu smokes today. A single-turn in-place refactor would break all of them simultaneously. The parallel- file pattern lets each downstream consumer migrate one at a time in a separate turn, with no smoke regression at any point. Once all consumers migrate, the original nx_chacha20.nx becomes a thin backwards-compat wrapper (or deletable). API differs from nx_chacha20 by adding `arena: *NxArena` as the first parameter and renaming functions with `_pure` suffix so the two files can be co-imported without symbol collision: chacha20_block(key, counter, nonce, out) -> chacha20_block_pure(arena, key, counter, nonce, out) chacha20_encrypt(key, counter, nonce, in, n, out) -> chacha20_encrypt_pure(arena, key, counter, nonce, in, n, out) Helpers (load_u32_le / store_u32_le / u32_mask / rotl32 / qr) are duplicated with `pure_` prefix to avoid collision with the original module's same-named helpers. Arena budget: chacha20_block_pure uses 2 * 128 = 256 bytes per call (state + init snapshot). chacha20_encrypt_pure uses an additional 64 bytes (per-block keystream output). Caller should size the arena accordingly (256 + 64 = 320 bytes per encryption call; for back-to-back blocks the arena can be reset between calls).