pool: chunk_at never reports neighbours for VS-backend chunks

[glslang]

From claude-review on #80. Regression introduced by #80.

neighbourhood_at's touching check compares left.end() with right.header_address. For VS spans header_address is the physical _POOL_HEADER location (chunk_start + vs_header_size), while end() is usable_address + size, collapsing to the raw chunk end. For two physically adjacent VS chunks these differ by exactly vs_header_size (0x10 on x64), so touching is always false and previous/next are always None for any VS allocation.

That is precisely the question chunk_at exists to answer, so the contiguity fix disabled the feature for one whole backend.

Why the tests missed it: they build spans with PoolSpan::allocation, which sets usable_address == header_address (LFH/Segment geometry) and never reproduces the VS offset. Any fix needs a VS-shaped fixture.

Options: compare raw chunk extents rather than mixing end() with header_address; or have adjacency account for vs_header_size.

[glslang]

Partially addressed in #80, but left open deliberately — the fix is unverified.

touching now only requires contiguity where header_address == usable_address (LFH/Segment), skipping the check otherwise. That can only ever restore neighbours, never drop them, so it is safe. But I could not demonstrate it fixes the reported bug.

I wrote a VS-shaped fixture and mutation-checked it by restoring the strict comparison — the test passed either way, so it was exercising nothing. My fixture had accidentally made the spans adjacent under the strict rule too. I removed the test rather than ship one that cannot fail.

What is still needed: the real VS span geometry — specifically whether header_address is the chunk start or chunk_start + vs_header_size, and where usable_address sits relative to it. Deriving that from walk_vs against a live VS allocation, then a fixture built from those real values, is the way to close this. Guessing at the offsets is what this area has already cost several rounds.

[glslang]

Fixed on main by ce8bce2, which never referenced the issue. Verified against the current code and pinned by a test in #102 — none of the three had one, which is why they were reopenable by accident:

• pool: SessionKey.target makes the layout cache grow without bound #84: the rule lived in the caller as a SessionKey { target: 0, .. } before the call. Writing the test found the cache still keyed on the whole session when called directly, so the narrowing moved into LayoutCache as a LayoutKey it derives itself.
• pool: chunk_at never reports neighbours for VS-backend chunks #85: needed a VS-shaped fixture, which is exactly why it was missed — every test built spans with PoolSpan::allocation, whose LFH geometry puts header_address and usable_address at the same address. The new one fails against the pre-fix comparison, checked by restoring it.
• pool: walk_special_pool abandons a region on one bad page header #86: the page-granular skip now has a test that a bad page costs that page only.

Closing here; #102 carries the tests.