Retention and erasure in the evidence archive

Generated with the help of an LLM.

Problem/Motivation

1.0.0-alpha4 ships the evidence archive with this known issue: it has no retention and no delete. While it is on, the table grows by one row per verifier read; deleting the file or its content erases the document and keeps the row, and only uninstalling the module removes the rows.

That stands in the way of a beta, which promises a stable schema and configuration:

• A document can carry the certificate of the person who signed. A site that must keep personal data no longer than needed has no period it can set.
• When a named person asks for their data to be erased, the only routes are deleting the file or the content it was read for, or SQL.
• The table grows without a limit the site can set.

The constraint is ADR-0009: records are hash-chained, and it decided erase, do not delete. Erasing a document leaves the chain whole; deleting a row leaves a hole the status report calls broken.

Proposed resolution

• archive.erase_after_days (default 0, keep for good): cron erases the documents of records read longer ago than that. Rows stay; the chain is untouched. It runs with the archive switched off too.
• archive.delete_after_days (default 0): cron deletes records from the oldest end only, never the newest one. The first record kept and its prev_hash are stored as the chain's start (State) and logged, and the status report walks from there. Before deleting, the rows to go are checked against the chain; if one does not fit, nothing is deleted and an error is logged, so retention never removes the evidence of a change. A deletion anywhere else still shows as a break. This is ADR-0010, which amends ADR-0009.
• An administrator (Administer content credentials, plus access to the record) can erase one record's document from its view, through a confirm form. The log names the user ID.
• The view says why a document is gone: the file was deleted, the content was deleted, the period passed, or an administrator erased it. That reason is a new nullable column, erased_reason, outside the hash (update 11003, which also adds the two settings).
• The form refuses a negative or non-integer period, and a delete period below the erase period when both are set.
• At most 500 records per kind per cron run, oldest first; no run reads a document.

The defaults change nothing for a site updated from alpha4.

Remaining tasks

• Failing tests, then the code.
• README and CHANGELOG: replace the known issue.

Out of scope

• A list page of records.
• Deleting a single row other than from the oldest end.
• Removing kept trust lists that no remaining record names.