Persist the sweep's notices in the record, and let --ls read them

[blooop]

Build the resolution of #480: the detached sweep's notices land in the record, and --ls reads them.

Scope, per the decision:

• A per-repo last-sweep note in metadata.json beside last_fetched, overwritten on every sweep (bounded by construction, no rotation, no new file). A successful sweep clears it; a refused pack or failed fetch writes the repository and git's own words.
• dl --ls and --ls --json are the reading surface. The table gets a terse marker; the JSON carries the note verbatim. Nothing new prints on the launch path.
• Not a usize/string that conflates "no note" with "could not read": absence and presence are distinct states, per the map's constructive-modeling defaults.
• Test shape, from the ticket: a sweep whose pack-refs refuses leaves the refusal readable in the record and visible in --ls, asserted end to end. Today no test can distinguish the notice being raised from being read; this closes that.

Facts already verified on the map (fact-finder trace, 2026-08-29): ProcessRunner::detach nulls all three fds (devlaunch-runner/src/lib.rs:660); the --update-cache child's say() is eprintln! into that null (dl/src/commands.rs:346, :355); there is no existing persist-and-print mechanism — the #481 retired-key notice re-derives from config.toml on every run and writes nothing — so this deliberately introduces the first background-learned condition that survives to a foreground run.

[blooop]

Claimed 2026-08-29: build in progress from an interactive session (agent in an isolated worktree), managed by session devlaunch-2b as part of closing out map #444. PR to follow. If you are another session looking at this ticket, pick a different one.

[blooop]

Built in #519.

The record is BaseRepository.last_sweep: a SweepTrouble arm plus git's own
words, said: null where nothing spoke. Overwritten on every pass that acts on a
repository, cleared by a clean one, left alone by a pass that attempted nothing
(not due, contended, lock unavailable) so silence about an untouched repository
never reads as a clean sweep.

Three states rather than two, as the ticket asked: the key is absent when
there is nothing to say, an object when there is, and a stored value this build
cannot read is a NotRebuilt and goes the way an unparsable last_fetched
already goes (#67), reported with the original preserved. No empty string
standing in for silence.

dl --ls prints one line per troubled repository under the table, on stderr:

Last cache sweep of blooop/devlaunch: could not pack the refs it fetched: fatal: unable to create 'packed-refs.lock': Permission denied

Per repository rather than a column, because the note is about a bare clone: two
workspaces of one repository share a note, and a repository with no workspace
still has one to report and no row to report it in. dl --ls --json carries it
as lastSweep on the rows whose repository has one, appended and absent unless
there is a note, so wf's document is byte for byte unchanged on a clean cache.

The red test is end to end at the binary boundary
(a_pack_the_sweep_could_not_do_is_readable_when_somebody_next_lists): a git
on the run's PATH that refuses pack-refs, dl --update-cache --force, then the
refusal read back out of metadata.json, dl --ls and dl --ls --json.
Verified red with the record write disabled.

One property given up and named in the PR: dl --ls's table now reads
metadata.json, through a new session::open_storage that still skips the
config and the cache migration.

docs/cleanup.md's "That notice reaches nobody today" paragraph is rewritten:
the notice still reaches nobody, and the record is what does.