Correct four documentation claims ahead of the 1.0.0 tag

Final pre-tag verification found four places where the docs did not
match the shipped artifact.

`TODO.md` `# Status` said the tag was held on a durability defect that
has since landed. Rewritten to record that it landed, without naming a
remaining blocker whose issue number would falsify the file the moment
it closes. `# Next Step` opened with "Land <that issue>" and is
corrected the same way.

The README Package Layout tree omitted `internal/reqtls`,
`internal/ciscript` and `internal/versionscript`, all three of which
exist; `reqtls` is named repeatedly in the surrounding prose as the
TLS predicate.

The README Authenticated Endpoints table omitted three live routes,
verified against `internal/server/routes.go`: `GET` and `POST` on
`/source/{id}/targets/{targetID}/edit`, and `GET
/source/{id}/logs/{eventID}/body`.

The Rationale section sold "Guaranteed delivery" without saying which
guarantee. The engine deliberately implements at-least-once: a send
whose bookkeeping write fails is left recoverable and sent again by
the pending sweep or the next restart. Stated plainly, with the
consequence for receivers.

Documentation only; no behaviour change.

TODO.md

@@ -25,11 +25,20 @@ file records where the project is, not what is in flight: a sentence
 whose truth depends on a branch being unmerged is wrong the moment it
 merges, and this file has been wrong that way before.
 
-The tag is held on a durability defect
-(https://git.eeqj.de/sneak/webhooker/issues/256): a concurrent reader
-of a per-webhook event database strands delivered webhooks at
-`pending`, and the next restart re-delivers them. That issue gates
-`v1.0.0`, and is where the fix's own state is tracked.
+The durability defect that held the tag has landed
+(https://git.eeqj.de/sneak/webhooker/issues/256, commit `8d64259`).
+Every SQLite handle opens with WAL journaling and a busy timeout, a
+bookkeeping write that fails leaves its delivery in a recoverable
+state rather than a lying one, and recovery skips a delivery that
+already has a successful result row. Final pre-tag verification
+exercised it and confirmed it holds. Whatever the milestone still
+shows open is what remains before `v1.0.0`.
+
+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 deliberate — the alternative is a silent lost
+delivery — and the README says so under Rationale. It is not a defect
+to re-file.
 
 One caveat on reading a green check: a docs-only commit deliberately
 replays from the layer cache
@@ -39,11 +48,11 @@ commit invalidates the `COPY` layer and genuinely executes.
 
 # Next Step
 
-Land https://git.eeqj.de/sneak/webhooker/issues/256, then clear the
-rest of the open 1.0.0 milestone and tag `v1.0.0`. Merging `next` into
-`main` is a separate act from tagging and waits on neither of those:
-`next` is kept mergeable at all times, which is the point of the
-branch.
+Clear the rest of the open 1.0.0 milestone
+(https://git.eeqj.de/sneak/webhooker/milestone/9) and tag `v1.0.0`.
+Merging `next` into `main` is a separate act from tagging and waits on
+neither of those: `next` is kept mergeable at all times, which is the
+point of the branch.
 
 # Completed Steps