feat(booth): per-row link removal + render the link board as real UI

The standing link board is the one MULTI-WRITER booth -- every agent session
appends operator-facing URLs to it. "Delete the folder" was the only
granularity available, so removing one dead link meant hand-editing markdown.
It is 32 rows and only grows.

  booth links                 row number, entry id, raw row
  booth unlink 3              by row number
  booth unlink 8b40e0a5       by entry id (what the UI's x posts)
  POST /b/<name>/unlink       form field `entry` = content id

ROWS ARE ADDRESSED BY CONTENT ID, NEVER BY POSITION. The board is append-only
and multi-writer: another session can post between listing it and clicking x,
and an index would then delete a neighbour. An id either matches the row you
saw or matches nothing. A row number typed at the CLI is resolved to its id
BEFORE anything is deleted. Appends and prunes now take the same flock on
.links.lock, so a post cannot be lost inside a prune's read-modify-write.

UI: a booth carrying links.md renders as rows -- description, URL, provenance,
copy button, per-row x -- instead of a markdown blob. links.md is filtered out
of the gallery so it does not appear twice; the header counts LINKS not files;
the empty-state and the one-click "Wipe now" both stand down for a board (same
rule as the kept lane: nothing durable is one click from gone).

booth/links.py extracted, STDLIB ONLY. The CLI needs this logic and must not
require the service venv -- importing app.py drags in FastAPI, so deleting a
line from a text file would have needed a web framework installed.

THREE BUGS FOUND BY TESTING, all in the shell wrapper while the module was
correct throughout -- module-only tests would have caught none of them:

- `[ "$n" -eq 0 ] && echo ...` as the LAST statement made `booth links` exit 1
  whenever the board had rows. `unlink`'s index lookup calls it inside $( )
  under `set -e`, so a successful listing killed the caller and the removal
  silently did nothing while reporting success.
- ids are 8 hex chars and roughly one in forty is ALL DIGITS; those were read
  as row numbers, resolved to nothing, and removed nothing. Now disambiguated
  by the id's actual shape, not by "is it numeric".
- filtering links.md out of the gallery left `items` empty, so a full board
  rendered "This booth is empty" and an empty <div class="gallery"> under 32
  visible rows.

87 tests (was 76): parser tolerance of hand-written prose, content-id
stability across concurrent appends, removal precision, UI branch behaviour
for board/normal/empty booths, and subprocess CLI tests pinning the two shell
bugs. Deployed to nh3-dev and verified against the live 32-row board
read-only; board file byte-identical afterwards.

README.md

@@ -50,6 +50,10 @@ still ephemeral, so nobody inherits a cleanup chore they didn't ask for.
 booth keep   my-board      # drop the sentinel — exempt from the sweep, forever
 booth unkeep my-board      # release the pin — the board rejoins the sweep
 booth rm     my-board      # delete it NOW (works on kept boards; says so when it was kept)
+
+booth links                # list the standing link board: row number, entry id, the row
+booth unlink 3             # remove row 3
+booth unlink 8b40e0a5      # or remove by entry id (what the web UI's × posts)
 ```
 
 It is just a file, so the manual forms work identically and are the honest
@@ -135,10 +139,42 @@ to a safe basename (no path traversal).
 | `POST /b/<name>/delete` | Wipe a booth (the UI's "Wipe now" button) |
 | `POST /b/<name>/keep` | Pin a booth — exempt from the sweep |
 | `POST /b/<name>/unkeep` | Release the pin (the UI's "release" button on kept cards) |
+| `POST /b/<name>/unlink` | Remove ONE row from a link board (form field `entry` = content id) |
 | `DELETE /b/<name>` | Wipe a booth (curl/API) |
 | `GET /healthz` | `{ok, ttl_hours, booths}` — Homepage siteMonitor target |
 
 
+### The standing link board
+
+A booth containing `links.md` is the fleet's **standing link board**: every
+agent session appends operator-facing URLs to it so they outlive the terminal
+scrollback that would bury them. It is the one booth where the useful
+granularity is the **row**, not the folder — a dead link has to be removable
+without taking the other thirty with it.
+
+It renders as real UI, not a markdown blob: each row shows the description,
+URL and provenance (who posted it, when), with a copy button and a per-row ×.
+
+```bash
+booth links                # row number, entry id, raw row
+booth unlink 3             # by row number
+booth unlink 8b40e0a5      # by entry id — what the × posts
+```
+
+**Rows are addressed by CONTENT ID, never by position.** The board is
+append-only and multi-writer: another session can post between the moment you
+list it and the moment you remove a row, so an index would delete a neighbour.
+An id either matches the row you saw or matches nothing. A row number typed at
+the CLI is resolved to its id *before* anything is deleted.
+
+An id is exactly 8 hex characters, which is how the CLI tells ids from row
+numbers — roughly one id in forty is all digits, so "is it numeric" is not a
+safe test.
+
+Appends (`booth link`) and prunes (`booth unlink`, the ×) take the same
+`flock` on `.links.lock`, so a post cannot be lost inside a prune's
+read-modify-write window.
+
 ### Deleting a kept board
 
 Kept boards have no × in the UI on purpose — a one-click wipe next to the