### Problem `SegmentRestorer::restoreSegment()` is meant for a segment whose rows have been live-purged. Called on a segment whose rows are still live (archived but never purged, which is the state every segment is in between `archive_after` and `live_purge_after`), it does three things wrong, in this order: 1. **It writes the `segment_restored` chain event first** (Step 1, under the chain lock), before it has looked at whether the range is free. Only then does Step 2 try to INSERT the archived rows at their original ids, and the PRIMARY KEY refuses them. 2. **The refusal blames another chain.** The catch in `replayArchivedRows()` rewrites the collision as `archive id=1 collides with an existing audit_trail row on chain "webdav" … this slot is already taken by another chain that has not been live-purged`, when the row in the slot is this chain's own, still live. 3. **The orphan event is permanent and the index now disagrees with the chain.** `SegmentIndex::replaySegmentEvents()` applies a `segment_restored` event as `live_purged_at = 0; live_purged_event_id = <event id>`, while the stored segment row still has `live_purged_event_id = 0`. So `compareIndexToChain()` reports the segment as `altered` from then on, the status report carries a segment-index error, and `drush audit_trail:reindex-segments` would "repair" the index into pointing at an event that describes a restore that never happened. The outer catch then tells the operator that a retry "will be refused by the Step 0 in-flight check. Manual recovery required". The archive restore form never offers this: `AuditTrailSegmentsController::buildOperationsCell()` shows Restore only when `$live === 0 && $total > 0`, and `AuditTrailArchiveRestoreForm`'s class docblock says it "refuses if the target range still has live rows". Neither the service nor `drush audit_trail:archive-restore --id=N` holds that rule, so a drush call or an API caller hits all three defects. ### Steps to reproduce Kernel: log two rows on a chain, archive the range `[1, 2]`, do **not** purge, call `restoreSegment()` on the segment. - Before: a `RuntimeException` naming another chain, a `segment_restored` row on the chain (id 5 in the existing test), and `compareIndexToChain()` answering `agrees => FALSE`. - The existing `PurgeRestoreTest::testRestoreRefusesWhenTargetIdSlotIsOccupied()` passes on 1.x because it asserts only that the message contains "collides with an existing audit_trail row". ### Proposed resolution Refuse in `restoreSegment()` before Step 1: ask `ChainRepository::getRowCountInRange($chain, $from_id, $to_id)` and throw when it is above zero, naming the count and the range, and saying that only a live-purged segment can be restored. Nothing is written by a refused call. Keep the PRIMARY KEY path in `replayArchivedRows()` for the case it describes correctly: a row of **another** chain occupying an id in the range, which a pre-check cannot exclude (interleaved ids). Widen `testRestoreRefusesWhenTargetIdSlotIsOccupied()` to pin the two facts the message hid: no `segment_restored` row is written, and `compareIndexToChain()` still agrees. ### Disclosure This issue was written by an AI assistant (Claude Code) as part of a complete audit of the module requested by the maintainer. The defect was confirmed by widening the existing kernel test and running it against 1.x before filing; the merge request and its test were written by the same assistant and are reviewed by the maintainer.