fix: honor allocation limits at boundary cases

[besmpl]

Summary

• reserve enough internal region nodes to honor the documented maxAllocs count even when allocations split free regions
• track active allocations separately from structural metadata and keep fragmented allocation/coalescing O(1)
• reject aligned requests whose padded size would overflow uint32
• add one-slot, zero-capacity, fragmented-capacity, reuse, accounting, overflow, and metadata-exhaustion regressions

Why

The initial free region used one of the advertised allocation nodes. As a result, New(1024, 1).Allocate(1) attempted to create a remainder through the freelist sentinel and panicked instead of returning the single supported allocation. Fragmented layouts could similarly exhaust structural nodes before reaching maxAllocs.

Free regions are never adjacent after coalescing, so with K active allocations there are at most K+1 free regions. A preallocated 2*maxAllocs node pool (or one initial node for a zero-capacity allocator) therefore covers every reachable layout while the new active count enforces the public limit.

Separately, AllocateAligned previously allowed size + alignment - 1 to wrap, potentially returning a tiny successful allocation for a near-MaxUint32 request.

Verification

• go test ./...
• go test -race ./...
• go build ./...
• go vet ./...
• golangci-lint run --timeout=5m
• go test -covermode=atomic -coverprofile=coverage.out ./... — 99.5% total statement coverage and 100% of changed production statements (42/42; no uncovered changed blocks)
• randomized aligned and unaligned fragmentation stress
• allocator fuzz smoke tests
• hot-path benchmarks remain 0 B/op, 0 allocs/op
• gofmt and git diff --check

CI note: GitHub marks this fork pull request's workflow run as action_required; upstream Actions and the Codecov upload will start after a repository maintainer approves the run.