### Problem #3620407 stops `SegmentRestorer::restoreSegment()` writing an orphan `segment_restored` event when the segment's **own** rows are still in its range. A row of **another chain** sitting on one of the archived ids produces the identical outcome, and that half is still open: 1. the pre-flight count is scoped to the segment's chain, so it answers 0; 2. Step 1 writes the `segment_restored` event; 3. Step 2 trips the PRIMARY KEY on the occupied id and rolls the row replay back; 4. the event stays. `SegmentIndex::replaySegmentEvents()` reads a `segment_restored` event as the live-purge pointer move it would have been, so `compareIndexToChain()` reports the segment `altered` from then on and the status report carries a segment-index error nothing clears. ### Steps to reproduce `PurgeRestoreTest::testRestoreRefusesCrossChainIdCollision()` already builds the state. Add two assertions to it and they fail against 1.x and against the #3620407 branch alike: ``` no segment_restored row on the chain expected 0, got 1 compareIndexToChain('webdav')['agrees'] expected TRUE, got FALSE ``` ### Why the #3620407 guard does not cover it, and must not be widened The obvious widening, counting the range across every chain rather than one, is wrong and the suite says so: `testRestoreMultiChainInterleavedIdsLandAtOriginalSlots()` goes red. Interleaved chains leave their own rows at ids inside a segment's range, untouched by its live-purge, and a restore that is perfectly free to proceed then reads as blocked. The range is a span; what the replay needs is the **set of ids** it will insert at, and the two coincide only on the segment's own chain. ### Reachability Not reachable from the module's own writes on one site. Ids are a single unreused sequence, the logger takes them at the head, above every archived range, and no two archived rows anywhere share an id, so nothing the module does can put a foreign row on an archived id. It is reachable through `importFromFile()`, which is the path restore exists for: an archive pulled off WORM storage carries the id space of the site that wrote it, and on the site importing it those ids belong to whoever happens to hold them. The restore was always going to fail there. What it must not do is leave the attestation behind. ### Proposed resolution Ask the occupancy question about the archived ids rather than about the range, before Step 1. The ids live in the archive file, one per `row` envelope, and the pre-flight does not have them: `SegmentReader::verifyArchivedSegment()` streams the file twice already (`hash_file()` and `ArchiveEnvelope::replayRows()`) and returns neither. So the work is one of: - have the replay that already runs return the ids it saw, and check those against `audit_trail` in chunks; or - refuse at import instead, where the foreign id space enters, which needs the same id set and gets it from the same file. Either way it is a different mechanism from #3620407's, with its own cost on a path that is already O(file), which is why it is its own issue rather than a wider condition on that one. ### Disclosure This issue was written by an AI assistant (Claude Code) during an audit of the #3620407 merge request requested by the maintainer. The defect was confirmed by adding the two assertions above to the existing test and watching them fail; the widening that does not work was confirmed by watching the interleaved-chain test go red. Any merge request is reviewed by the maintainer.