## Problem/Motivation ### 1. A chain wipe leaves no tamper-evident trace Found in the second release audit of 1.x at `8af6d2c`. *Clear chain data* (`AuditTrailChainDeleteForm`) and *Delete chain* (`AuditTrailChainEntityDeleteForm`) both call `ChainArchiver::deleteChain()`. It deletes every `audit_trail` row of the chain, its segments, its acknowledgments, its staged entries and its **checkpoints**, unlinks the archive files, and then logs one `critical` message with `'audit_trail' => FALSE`, which reaches dblog and syslog only. Nothing tamper-evident records that the chain was wiped, by whom, or which head was erased: - The threat model counts on a signed checkpoint to catch truncation: a checkpoint names a row that is now missing (`docs/threat-model.md`, "Truncation by an attacker who deletes consistently"). The wipe deletes the checkpoints itself. - Afterwards the chain verifies: it is empty, or it restarts from genesis on the next write. It drops out of `ChainRepository::listChains()` until then. - A TSA timestamp of the old head is deleted with the rows. So one click by a holder of *Administer the audit trail* does what the threat model calls undetectable, without database access. The actor matrix in `docs/threat-model.md` has no row for that permission. ### Proposed resolution for 1 - At the end of `deleteChain()`, under the chain-write lock it already holds and after the deletes, write a signed `chain_cleared` row on the same chain. It becomes the chain's new genesis and records, in its permanent bucket, the erased head (id and hash) and how many rows, segments, acknowledgments, checkpoints and staged entries went. The actor comes from the forensic stamp, as on every other row. - The chain then restarts with a record of its own wipe: the verifier reads one genesis row that says what came before, and a timestamped head no longer matches. - *Delete chain* removes the chain entity, and the `chain_cleared` row stays under the chain id, so the deletion is still on record. - Add the operator row to the actor matrix and correct the texts that say the chain "disappears entirely". - Test: clear a chain with rows, then exactly one row remains, a `chain_cleared` row naming the erased head. Same for *Delete chain*. ### 2. Five defects Five more defects from the same audit, each reachable on a normal site (filed as #3620465, folded in here to keep one merge request): 1. **Segment confirm pages crash when the archive directory is refused.** `SegmentReader::loadSegment()` fills a display-only `archive_path` by calling `ArchiveLocation::resolve()`. That call creates the directory, and throws when the directory is blank, web-accessible or not writable. `SegmentOperationFormBase::buildForm()` (the *Archive* confirm page, which never shows the path) and `AuditTrailArchiveRestoreForm::buildForm()` call it unguarded, so both pages fail with a 500. The segments list catches the same case and shows a warning. A page that only reads also creates directories. 2. **URL aliases are missing from entity snapshots.** `EntitySnapshot::getMainPropertyDeltas()` reads a field item as `value ?? target_id ?? uri`. A field whose main property is something else is recorded as `null`, for example the path field (main property `alias`), a comment field (`status`), or a contrib type. An alias change is recorded as `null` to `null`, and the entry page files it under "unchanged". 3. **Pending secrets are reported as retired.** When no secret is active, `SecretKeyChecker` says "All `audit_trail_secret` entities are retired". That is also the state right after adding the first secret, which is pending until somebody chooses *Use for signing*. 4. **The user_auth schema requires keys the code treats as optional.** `AuditTrailUserAuthHooks::isEventEnabled()` reads a missing `events.<name>` as enabled, but the schema requires every event key under `FullyValidatable`. Config without one records the event and reports a schema violation. #3620449 fixed the same mismatch for the file bridge only. 5. **Savepoint markers are never freed.** `AuditTrailChainWriter::markPendingWrites()` stores one entry per call (about 400 bytes) and nothing removes it. The documented pattern is one marker per savepoint, so a migration or queue worker grows memory with every item: 100,000 savepoints take 40 MB. ### Proposed resolution for 2 1. `loadSegment()` stops building the path. The restore form builds it inside a `try`, shows the refusal and offers no confirm button. 2. Read the item's own main property (`getMainPropertyName()`), and fall back to the current guess only when the type declares none. 3. Reuse the none / pending / retired distinction the secrets page already makes. 4. Mark the user_auth event keys and `events` with `requiredKey: false`, as the file bridge does, and give the two readers one shared method. 5. Drop the markers when the outermost transaction ends. Each defect gets a test that fails on 1.x. ## Remaining tasks - [x] Fixes and tests - [ ] Review ## User interface changes The clear and delete confirm pages say that the wipe is recorded on the chain. The segment confirm pages show a message instead of an error page. The status report distinguishes pending from retired secrets. ## API changes `ChainArchiver::deleteChain()` takes the account doing the wipe. ## Data model changes None. ## AI disclosure AI-Generated: Yes (Claude Code was used to help draft this issue summary and to write the fixes and their tests during a release audit. I reviewed both, and each new test was confirmed to fail against 1.x and to pass with the change.)