todo: one file per item, grouped by theme, with a generated index

TODO.md had reached 1050 lines and 72 open items across 28 sections, read mostly
on a phone. It is now a directory: todo/<theme>/<item>.md, one card per file, with
frontmatter carrying id, status, created date and order, and the prose body copied
across verbatim. TODO.md becomes a generated index (bun run todo:index).

Dates: where an item's prose stated one it is used; otherwise its old section's;
otherwise 2026-08-20, floored at the day before the split rather than invented.
date_source records which.

Shaped for a two-way Kanban board, filed as todo/tooling — a card is a file, id is
the identity, frontmatter is the machine's half and the body is the owner's.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

todo/release-binaries/_index.md

@@ -0,0 +1,19 @@
+---
+theme: release-binaries
+heading: "Release-binary dependencies (2026-08-19)"
+kind: theme
+---
+
+Built: a plugin can declare `release: { url, identify }` for a dependency no package manager carries.
+Gitea's `tea` is the motivating case and the first user.
+
+Two things it does NOT do, both deliberate and both worth knowing:
+
+- **No checksum.** The download is verified by RUNNING it through the same `identify` rule the probe
+  uses, which catches an HTML error page, a truncated file and a wrong-architecture build — none of them
+  print what the plugin said to look for. It does not catch a compromised upstream. A checksum per
+  os/arch is a table that goes stale every release and would stop installs the day upstream re-cuts a
+  tag; HTTPS and a URL the owner reads in the install dialog is what stands behind it today.
+- **The version is pinned in the manifest.** `tea` is fixed at 0.15.1, so a new release needs a plugin
+  update. That is the right default — an install that silently fetches whatever is latest is not
+  reproducible — but there is no "check for a newer one" anywhere.