Correct release-blocking documentation inaccuracies (closes #141)

The README env table was missing RETENTION_SWEEP_INTERVAL, TODO.md omitted five landed units, and three passages sold manual redelivery in the present tense when nothing implements it. The same false claim was corrected in the doc comment on failUnretryableRetry, which was its source text. Also removes a console.log from the shipped static asset.

README.md

@@ -93,7 +93,7 @@ TTY detection, and security headers are always applied.
 | `METRICS_USERNAME`      | Basic auth username for `/metrics`  | `""`     |
 | `METRICS_PASSWORD`      | Basic auth password for `/metrics`  | `""`     |
 | `SENTRY_DSN`            | Sentry error reporting DSN          | `""`     |
-| `RETENTION_SWEEP_INTERVAL` | Retention reaper period (Go duration, must be positive) | `1h` |
+| `RETENTION_SWEEP_INTERVAL` | How often the retention reaper and archive sweeper run (Go duration, must be positive) | `1h` |
 | `SESSION_IDLE_TIMEOUT`  | Idle session timeout (Go duration)  | `24h`    |
 | `RECEIVER_RATE_LIMIT`   | Receiver requests/minute per IP per entrypoint | `120` |
 | `TRUSTED_PROXIES`       | CIDRs whose forwarded headers are trusted | `""` (none) |
@@ -265,9 +265,10 @@ webhooker solves this by acting as a durable intermediary:
    targets simultaneously. This enables patterns like forwarding a
    GitHub webhook to both a deployment service and a Slack channel.
 
-5. **Replay** — Stored events can be manually redelivered for debugging
-   or testing, without requiring the original sender to fire the webhook
-   again.
+5. **Replay** (not yet implemented) — Every received event is stored in
+   full, which is what manual redelivery for debugging or testing will
+   be built on. No redelivery exists today, in the web UI or the API;
+   see [TODO.md](TODO.md).
 
 ### Use Cases
 
@@ -277,6 +278,7 @@ webhooker solves this by acting as a durable intermediary:
   size, and delivery performance
 - **Debugging** and introspection of webhook payloads in the web UI
 - **Replay** of webhook events for application testing and development
+  (planned; not yet implemented)
 - **Fan-out** delivery of a single webhook to multiple downstream
   targets
 - **High-availability ingestion** for delivery to less reliable backend
@@ -502,7 +504,7 @@ A programmatic access credential for API authentication.
 #### Event
 
 A captured incoming webhook request. Stores the complete HTTP request
-data for replay and auditing.
+data for auditing and for the planned replay capability.
 
 | Field          | Type   | Description |
 | -------------- | ------ | ----------- |
@@ -784,9 +786,10 @@ unknown) one while one of its deliveries is still `retrying`, both
 recovery paths above terminally mark that delivery `failed` and record a
 `DeliveryResult` naming the current target type as the reason, logging it
 at warn level. The delivery is not re-dispatched under the new type — the
-operator never asked for that delivery — and the event itself remains
-stored in the per-webhook event database, so it can be redelivered
-manually.
+operator never asked for that delivery — and while the event itself
+remains stored in the per-webhook event database, there is no way to
+redeliver it: manual redelivery is planned, not implemented (see
+[TODO.md](TODO.md)).
 
 ### Circuit Breaker (HTTP Targets with Retries)