[matrixarkai]

Four places told an operator that a store written before the routing-range stamp existed
has lost the range for good: routing_range_stamp.rs ("NOT RECOVERABLE ... nothing
recorded it"), lib.rs ("not recorded anywhere and cannot be inferred reliably"),
docs/runtime_tuning.md ("not recorded anywhere and cannot be recovered from the store"),
and a test's own failure message. The operator doc says the opposite fifteen lines
earlier: "a page's bucket is written onto its address when the page is appended".

The second sentence is the true one. A pre-stamp address CARRIED the bucket it was filed
under, in the rs field that was retired from BlockAddressWire later, beside the object
key the bucket was derived from. So the width is a solve rather than a guess:

bucket = start + FNV-1a-64(object_key) % width
=> width divides ( FNV-1a-64(object_key) - bucket )  for EVERY stored address
=> gcd those differences, keep the divisors above the largest bucket the store uses,
   and accept a candidate only if it reproduces EVERY recorded bucket

What is not being reopened

The DECLINED inference stands and is still documented: separating 0..1023 from the whole
keyspace by the SPREAD of the bucket keys is right "almost always", and a wrong range is
silent, which is the failure this stamp exists to prevent. This is a different question
asked of different evidence -- the recorded buckets rather than their range -- and its last
step is a check, so a wrong width is reported rather than adopted.

Measured

A 13 GB store written before the stamp existed: the gcd over 12,125 addresses is
4,294,967,295; exactly one divisor of that gcd exceeds the largest bucket the store uses
(4,294,914,071); and that width reproduces 12,125 of 12,125 recorded buckets. Since
routing_bucket_count is (end - start).saturating_add(1), that width is 0..u32::MAX --
the fallback this engine used before it recorded anything. Writing the stamp then moved the
refusal from routing_range_unstamped to routing_range_mismatch naming
0..4294967295 against 0..1023, so the store itself confirmed the solve.

What changes

Documentation and one refusal message. No behaviour: the load still refuses, and the engine
still does not solve the width itself -- those addresses are in the served index, and an
index old enough to carry no stamp is old enough that decode_index_bytes refuses its
format version before decoding it. Reading one is a job for a tool. What changes is that the
refusal and the runbook now point at the arithmetic instead of telling an operator the
answer is gone while it sits in their store.

The message keeps every substring its tests assert on, including the stamp file name and
"ingest into a new store".