Add debug relocation generation diagnostics for stale resolved views

[netkeep80]

Parent: #399
Related: #408, #418

Problem

PMM's resolved-pointer contract is intentionally semantic: raw pointers/references are ephemeral and become invalid when the arena base is replaced. Today, violating that rule usually manifests later as ASan/UBSan failure, corrupted state, or a difficult-to-localize invalid access.

A lightweight debug diagnostic could make relocation-lifetime mistakes fail near the violating boundary without changing persistent identity or production layout.

Goal

Evaluate and, if it stays zero-cost in release builds and non-persistent, add a manager/backend relocation generation counter usable by debug/test-only resolved-view diagnostics.

The generation is process-local diagnostic state, never persisted and never part of pptr identity.

Proposed model

• increment a generation/epoch whenever the active arena base can be replaced (resize/remap/load/attach/replacement paths as applicable);
• expose a cheap read-only generation query for tests/debug helpers;
• permit debug-only helpers to capture (raw pointer, generation) and assert that the generation has not changed before dereference;
• keep normal resolve() return types and persistent layouts unchanged;
• do not attempt to make arbitrary C++ pointers self-validating.

Required audit

Identify every path that can replace the active backend base and prove generation changes exactly when the old resolved views become invalid. Distinguish whole-arena relocation from allocation movement inside an unchanged arena and from ordinary deallocation.

Tests

• generation is stable across non-relocating allocations;
• generation changes when forced HeapStorage expansion replaces the base;
• load/attach/replacement paths follow the documented rule;
• debug helper detects an intentionally stale captured view after forced relocation;
• pptr identity continues to resolve correctly across generation changes.

Constraints / non-goals

• no persistent epoch field;
• no extra bits in pptr;
• no pinning or GC-style handles;
• no mandatory runtime overhead in release builds unless separately justified by measurement;
• no false promise that the mechanism can validate arbitrary raw pointers after deallocation.

Acceptance criteria

Either:

1. a compact zero-persistent-layout diagnostic is implemented and covered by tests, or
2. the issue is closed with concrete evidence that the mechanism would add disproportionate complexity/overhead and Relocation conformance matrix for persistent containers and forest state #418 sanitizer/conformance coverage is the preferred guard.

In the implementation case all compiler/sanitizer/generated-header/LOC/repo-guard gates must remain green.