Drop Completed Steps from TODO.md; the tracker is the record (closes #112)

Every issue branch added an entry to the same list, so each branch
conflicted with `next` as soon as another one landed. The tracker already
records what is done, in more detail than the list did.

The Workflow section now says the tracker is that record, in place of the
rule that issue branches leave this file alone. Status points to the 1.0.0
milestone for what is open, and Next Step says @sneak tags `v1.0.0` after
running webhooker in limited production. In Future Steps, the per-webhook
rate limit item says the receiver's server-wide limits already exist, the
delivery status and retry UI item is gone because the event log, replay and
resubmit cover it, and two items under Later name what already exists.

Model: opus-5-5

TODO.md

@@ -17,8 +17,9 @@ is done and what is under way. This file keeps no list of either.
 
 # Status
 
-The 1.0.0 milestone (https://git.eeqj.de/sneak/webhooker/milestone/9) has no
+What is still open for 1.0.0 is in its milestone
-open issues, and `v1.0.0` is not tagged. Only @sneak cuts that tag.
+(https://git.eeqj.de/sneak/webhooker/milestone/9). `v1.0.0` is not tagged, and
+only @sneak tags it.
 
 Delivery is at-least-once by design, not by accident: a send whose result row
 does not land is attempted again, so a receiver can see a duplicate. That is
@@ -33,12 +34,9 @@ is kept mergeable at all times, which is the point of the branch.
 
 # Future Steps
 
-- Delivery status and retry management UI. Replay of a terminally failed
+- Per-webhook rate limits, set in the web UI and enforced in the receiver
-  delivery and per-attempt detail already landed
+  handler, on top of the receiver's existing limits, which `RECEIVER_RATE_LIMIT`
-  (https://git.eeqj.de/sneak/webhooker/issues/203,
+  sets for the whole server (see Rate Limiting in the README)
-  https://git.eeqj.de/sneak/webhooker/issues/202)
-- Per-webhook rate limiting in the receiver handler (per-webhook config plus
-  handler enforcement; global limits must not apply to receiver endpoints)
 - API key authentication for programmatic access (APIKey model exists; Bearer
   token middleware does not)
 - REST API v1