levain 0.6.4

The team view and its cockpit back-link, and levain doctor's continuity headroom line.

Added

• levain team view: a read-only localhost page over the team ledger. Four panes, one per question a lead asks: what waits on me (questions and tensions you own), where agents were stopped (acknowledgement counts per path, never per person), what is held by nobody, and what is in force (with an In Force filter and a path filter). It serves GET routes only, has no write path, binds loopback only and rides the cockpit's stylesheet and guards. --port (default 7450), --cockpit-url for the nav link, --recheck-days, --ack-flag.
• The cockpit links to running team views. Each running view publishes one entry under <levain home>/team-views/ and holds an exclusive file lock on it for its whole life; the cockpit's Team control lists the entries it cannot lock (a live view holds them) and links to them. Nothing is probed over the network, and the cockpit never deletes an entry; a newly started view removes entries no view holds. A process forked from a view without exec closes its copy of the lock at once. Served only by a loopback-bound cockpit to a loopback peer. The cockpit lists at most 8 views, judged in entry-name order within a one-second budget, and says "team list may be incomplete" whenever it stopped early, could not read the directory in full, or could not judge an entry; a registry fault answers 500 and the page keeps the list it had. Known limits: the registry needs a local filesystem for the levain home (NFS and some FUSE mounts emulate the lock; there the view prints that it is not registered and keeps serving); a view that is alive but wedged is still listed, and the browser shows the hang; past 8 live views, which ones show is decided by their random entry names, not by project or age; a registry directory that can never be read (a symlink, another user's directory) shows the same "may be incomplete" note as a transient failure; a temp file left by a killed view stays in the directory (it is never listed); a thread that forks while another thread is inside register() can give the child a copy of the lock before the at-fork hook knows about it.
• levain doctor reports each entity's continuity headroom against anneal's hard maximum. The new continuity headroom line reads the entity's continuity through its store (Store.load_continuity, strict UTF-8, as the next wrap will) and the schema persisted there, and says how many characters are used, the bound, and how many are left (flagging under 10%). It fails when the file is over the maximum (a wrap's save is refused unless it recomposes the continuity below it), when the file cannot be read or measured, and when the path exists but is not a regular file (it is never opened). It says nothing when there is no continuity file yet. Known limits: the regular-file check and the read are two steps, so a file swapped for a FIFO between them (a type swap by a concurrent writer; wraps rename regular files into place) would block the run, because closing it means re-implementing anneal's read; and a store with completed wraps whose continuity file has gone missing is not reported here (a verified .tmp recovery file can hold the memory, so "missing" needs anneal's recovery check, which this line does not run). The count is anneal's own: the file's characters minus the durable section (anneal_memory.durable.section_chars) against anneal_memory.schema.hard_max_chars; nothing is re-implemented here. It needs anneal-memory 0.9.33 or later, which levain already requires.