Correct allocator block size after shrinking

[stefanmaierhofer]

Summary

• update the surviving Block.Size before releasing a nonzero shrink tail in both MemoryManager and ChunkedMemoryManager
• keep Block.Size and the range passed to Use consistent with storage returned to the free list
• preserve offsets, alignment, retained prefix contents, free-list ordering/coalescing, and capacity trimming
• add shared backend-independent regressions for both allocator implementations

Coverage

The new tests use aligned, guarded allocations and verify:

• the reported size and the size passed to Use after shrinking
• unchanged backing storage, offset, alignment, retained prefix, and neighboring allocations
• immediate reuse of the exact released tail without overlapping live ranges
• coalescing of the retained and reused ranges after independent frees
• contiguous-manager capacity trimming and chunk release
• subsequent full-range allocation and release

On master, shrinking [0, 10) to five units leaves both allocator variants reporting [0, 10) through Block.Size and Use, while a new allocation receives [5, 10). The ranges therefore overlap.

The two focused regressions passed 100 consecutive Release runs (200 focused passes). A 50-test backend-independent maintained selection passed in both Debug and Release. The complete non-Windows solution builds cleanly in both configurations.

Performance

CPU-pinned warmed Release medians over ten alternating runs; each run used eleven no-GC samples of 50,000 independent shrink operations:

Operation	master	This PR	Allocation
MemoryManager shrink	221.825 ns	220.840 ns	213 B -> 213 B
ChunkedMemoryManager shrink	215.087 ns	213.568 ns	192 B -> 192 B

Both paths remain allocation-identical and show no throughput regression.

Fixes #166.