writ deploy leaves the links of removed sources dangling and drops them from the record: reconcile then reports a clean machine #960

The operation that ran was writ deploy, not writ upgrade (the owner, 2026-09-27: "we deployed. we did not upgrade."). Measured 2026-09-26 on DANOBLE-UD24-1: personal#232 deleted sixteen files from the layer; the next writ deploy (graph 64ee1699, 20:04Z) correctly stopped planning them, then replaced the record (#922) and left their links on disk, dangling, in no record. writ reconcile reads only the current record, so it reports the machine clean while ~/.local/bin/git-protect-encrypted-files, its man page and both completions, and the ~/.Personal-secrets links point at nothing. deploy.go has no stale, orphan or prune step.

Deploy is the operation that replaces the record, so it is the one that knows, at that moment, which links the replaced lifetime made and which of their sources are gone. The defect is that it drops them silently. What deploy does instead — unlink them, carry them into the new record for upgrade (#845's orphan row) to remove, or at least report them — is the design to rule on; a link whose target is no longer what writ made is never removed.

Plan and design documents

Epic: #450 · Feature: #845