fix: use atomic.Int64 for shard stats on 32-bit platforms

[somaz94]

On 386, arm and 32-bit mips the stats field of cacheShard is not 8-byte aligned (it sits at offset 132 on 386), so atomic.AddInt64 in hit() panics with "unaligned 64-bit atomic operation" on the first Get.

This moves the shard counters into a private struct of atomic.Int64, which Go keeps 8-byte aligned, as suggested in #368. The public Stats type keeps its int64 fields and JSON tags, so callers see no API change (#260 went to int32 instead).

It also fixes a data race. resetStats replaced the whole struct under the shard lock while hit() adds outside it, so each counter is now reset with Store(0) and the lock is not needed there. TestCacheResetStatsWhileReading fails under -race on main and passes here.

For the CI reproduction asked for in #368, there is a new GOARCH=386 go test step. The ubuntu runner executes 386 binaries natively, so qemu is not needed. On main this step fails with the same panic. It runs . and ./queue only, because the server tests use HardMaxCacheSize: 8192, and 8192 MiB in bytes wraps to 0 in a 32-bit int. That disables the cap, so TestInvalidPutWhenExceedShardCap gets 201 instead of 500. It looks like a separate bug, so I left it out.

Validation: with Go 1.27.2 and 1.26.9, go vet, golangci-lint v2.14.0 and go test -race -count=1 pass for all three packages, and the linux/386 test binaries for . and ./queue pass in a 386 container.

Fixes #368