2.5.1 — The harness link survives an unrelated journal refusal

Fixed

• init --harness-memory, which the SessionStart hook runs, restores the harness-memory symlink after a readable journal refusal that does not concern the link, such as two adoption lineages in one legacy history. In 2.5.0 the session started without project memory and nothing said why.
• The repair is decided and performed under the journal lock. It is withheld, with a WARNING ending in run journal --check, whenever a retained transaction, a history condition or a vault entry that is not a regular transaction file could own the link. Paths are compared as the filesystem reads them: symlinked parents, .., case, and two names of the same file.
• The same vault check now guards the repair when the journal cannot be read, when its lock cannot be taken, and when the vault's ignore entry cannot be written. A lock held by another validated-memory run withholds the repair.

Added

• status prints status: journal: N history condition(s) stop init; run journal --check, with a WARNING, when the inspection that journal --check performs finds history conditions. The exit code does not change.

Known limits

• The lock serialises validated-memory processes only. A process outside the plugin that replaces the harness path between the check and the relink is not guarded against; the relink never replaces a directory.
• init can still block on a vault transaction entry that is a symlink to a FIFO, as in 2.5.0. status reports such a vault as unreadable without opening it.

Decision record: ADR 0029.