Remove inbound request signature verification (closes #279)

The receiver verified an optional per-entrypoint HMAC or shared token
before accepting a request. That is removed outright: the entrypoint
UUID in the URL is the authentication secret, and possession of it
authorises submission. This reverses the feature added in fcead5d.

Deletes the internal/signature package, the signature_scheme and
signature_secret columns from Entrypoint along with their accessors,
the per-entrypoint secret form and its POST route, and the scheme
labelling in EntrypointView. Pre-1.0 with no installed base, so the
columns simply stop being written; there is no migration and no
compatibility path.

Header sanitisation goes with it. SanitizeHeaders existed to strip a
scheme's own credential header before the header map was stored and
forwarded; with no configured credential there is nothing to strip, so
the receiver marshals the headers as received.

The receiver's other protections are untouched: the 1 MB body cap, the
per-IP rate limiter, the 410 for a deactivated entrypoint and the 404
for an unknown UUID.

README.md

@@ -733,110 +733,18 @@ backups at rest and restrict who can read them.
   credential that was in a backup you cannot account for.
 - `webhooker.db` stores target config **unencrypted**, tracked at
   [issue #212](https://git.eeqj.de/sneak/webhooker/issues/212), next to
-  the session encryption key and the Argon2id password hashes. It also
-  holds each entrypoint's inbound signature secret in the clear, for
-  the reason given under
-  [Inbound Signature Verification](#inbound-signature-verification):
-  HMAC verification needs the key itself, so it cannot be hashed.
+  the session encryption key and the Argon2id password hashes.
 
-## Inbound Signature Verification
+## The entrypoint URL is the authentication secret
 
-A receiver URL is a bare v4 UUID in a path. That is unguessable, but it
-is not a credential: anyone who learns it — from a browser history, a
-proxy log, a screenshot, a copy-pasted support ticket — can post events
-that webhooker stores and forwards, and the inbound headers are passed
-on to your targets almost verbatim, so they also choose what the
-downstream service sees. Verification is how an entrypoint stops
-accepting anything that reaches its URL.
+The receiver verifies nothing about an inbound request. The UUID in an
+entrypoint's URL is its credential: anyone who holds that URL can
+submit events to it, and the receiver checks nothing else about the
+sender. Treat an entrypoint URL the way you would treat an API token.
 
-It is optional and configured per entrypoint. An entrypoint with no
-scheme selected is not verified, which is what every entrypoint was
-before this existed and what every entrypoint remains after an
-upgrade — enabling verification is always a deliberate act, and no
-existing deployment is locked out of its own receivers by installing a
-new version.
-
-When a scheme **is** selected, a request whose signature is missing,
-malformed or wrong is answered `401` and **nothing is stored**: no
-event row, no delivery row, no delivery attempt. Rejection happens
-after the body is read (the signature covers it) and before the first
-write.
-
-### Supported schemes
-
-| Scheme   | Header                | Check |
-| -------- | --------------------- | ----- |
-| `github` | `X-Hub-Signature-256` | HMAC-SHA256 of the raw request body under the shared secret, hex-encoded, prefixed `sha256=` |
-| `gitlab` | `X-Gitlab-Token`      | The header is the shared secret itself, compared as-is |
-
-Both comparisons run in constant time (`hmac.Equal`). The HMAC is
-computed over the request body exactly as received, before any parsing,
-and under the same 1 MB body cap every other request obeys — an
-unsigned sender cannot make webhooker buffer more than a signed one.
-
-GitHub's older SHA-1 `X-Hub-Signature` is **not** accepted. Neither is
-a GitHub digest sent without its `sha256=` prefix.
-
-### Configuring a sender
-
-The secret is a value you choose and enter in two places: at the sender
-and in webhooker. webhooker never generates or displays one, so there
-is no stored credential the UI can be made to reveal.
-
-1. Generate a secret, e.g. `openssl rand -hex 32`.
-2. In webhooker, open the webhook's page, find the entrypoint, and
-   click **Configure** (or **Rotate**, if it already has one). Select
-   the scheme and paste the secret. Surrounding whitespace is stripped,
-   so a value pasted with a trailing space still works; a secret whose
-   own first or last character is a space cannot be stored.
-3. At the sender:
-    - **GitHub** — repository (or organization) → Settings → Webhooks →
-      the hook → **Secret**. GitHub then signs every delivery with
-      `X-Hub-Signature-256`.
-    - **GitLab** — project → Settings → Webhooks → the hook → **Secret
-      token**. GitLab sends it verbatim as `X-Gitlab-Token`.
-
-**Rotation** is the same form: submit the new secret. Deliveries signed
-with the old secret are rejected from that moment, so change it at the
-sender in the same sitting. Selecting **None** removes verification and
-deletes the stored secret with it.
-
-The page shows which scheme an entrypoint uses and which header it
-reads, never the secret. The value is stored in the clear — HMAC
-verification needs the key itself, and a hash of it cannot recompute a
-sender's digest — so it is handled like the other credentials
-webhooker holds: excluded from JSON, kept out of templates by a
-projection (`handlers.EntrypointView`), and absent from every log line,
-including the ones written when verification fails.
-
-### The credential is not stored or forwarded
-
-Under the `gitlab` scheme the signature header **is** the secret. An
-accepted request's headers are persisted on the event and forwarded to
-every delivery target, so `X-Gitlab-Token` is removed from that copy
-before the event is written — otherwise every target operator, every
-backup and everyone with read access to `events-*.db` would hold the
-value needed to forge signed requests to the entrypoint it protects.
-The sender's other headers are untouched, and the request the receiver
-itself verifies against is not modified.
-
-The stripping is driven by the scheme's own description rather than by
-a header name, and a scheme is stripped unless it declares that its
-header carries a digest. `github` declares it: `X-Hub-Signature-256` is
-an HMAC over the body, from which the key cannot be recovered, so it is
-stored and forwarded intact. A scheme added later is stripped by
-default.
-
-### When configuration is broken
-
-An entrypoint whose stored scheme this build does not recognise, or
-which has one half of the scheme/secret pair and not the other, is
-answered `500` and stores nothing. It is not treated as unverified. The
-UI cannot create such a row — it rejects an unknown scheme with a `400`
-— so this covers a hand-edited database or a downgrade to a build that
-predates a scheme. Failing closed is the point: an entrypoint the
-operator believes is protected must never quietly go back to accepting
-anything.
+There is no way to rotate the UUID in place. To retire one, delete the
+entrypoint (or deactivate it, which answers `410`) and create a new
+one, then point the sender at the new URL.
 
 ## Entrypoints
 
@@ -1116,18 +1024,12 @@ the full request and creates an Event.
 | -------------- | ------- | ----------- |
 | `id`           | UUID    | Primary key |
 | `webhook_id`   | UUID    | Foreign key → Webhook |
-| `path`         | string  | Unique bare UUID, generated at creation. The `/webhook/` prefix is route only and is not stored: the receiver matches this column against the raw `{uuid}` path segment |
+| `path`         | string  | Unique bare UUID, generated at creation. The `/webhook/` prefix is route only and is not stored: the receiver matches this column against the raw `{uuid}` path segment. It is also the entrypoint's credential; see [The entrypoint URL is the authentication secret](#the-entrypoint-url-is-the-authentication-secret) |
 | `description`  | string  | Optional description |
 | `active`       | boolean | Whether this entrypoint accepts events (default: true) |
-| `signature_scheme` | string | How inbound requests are authenticated: `github`, `gitlab`, or empty for no verification (default: empty). See [Inbound Signature Verification](#inbound-signature-verification) |
-| `signature_secret` | string | The secret shared with the sender, stored in the clear because HMAC verification needs the key itself. Never marshalled to JSON, never rendered, never logged. Empty when no scheme is set |
 
 **Relations:** Belongs to Webhook.
 
-Both signature columns arrive through `AutoMigrate` with an empty
-default, so every entrypoint written before they existed migrates to
-"not configured" and keeps accepting the traffic it already accepted.
-
 A webhook can have multiple entrypoints. This allows separate URLs for
 different event sources that all feed into the same processing pipeline
 (e.g., one entrypoint for GitHub, another for Stripe, both routing to
@@ -1321,10 +1223,6 @@ fired twenty times at a backend stays traceable. Resubmitting the same
 event repeatedly is supported and is the point of the action — there is
 no in-flight refusal; the route's own rate limit is what bounds it.
 
-Inbound signature verification is not re-run on a resubmit. There is no
-inbound signature to check on a copy the operator submits, and the
-route is authenticated and CSRF-protected as an operator action.
-
 #### DeliveryResult
 
 The result of a single delivery attempt. Every attempt (including
@@ -1485,17 +1383,15 @@ External Service
 │             │     │  Stack       │     │   Handler    │
 └─────────────┘     └──────────────┘     └──────┬───────┘
                                                 │
-                     1. Look up Entrypoint by UUID
+                     1. Look up Entrypoint by UUID — 404 if unknown,
+                        410 if inactive
                      2. Read the body under the 1 MB cap
-                     3. Verify the signature, if the entrypoint has
-                        one configured — 401 and no writes if it
-                        fails (see Inbound Signature Verification)
-                     4. Capture full request as Event
-                     5. Create Delivery records for each active Target
-                     6. Build self-contained delivery.Task structs
+                     3. Capture full request as Event
+                     4. Create Delivery records for each active Target
+                     5. Build self-contained delivery.Task structs
                         (target config + event data inline for
                          bodies < 16 KiB)
-                     7. Notify Engine via channel (no DB read needed)
+                     6. Notify Engine via channel (no DB read needed)
                                                 │
                                                 ▼
                                         ┌──────────────┐
@@ -2300,7 +2196,6 @@ abuse limit later; they are tracked as future work.
 | `POST` | `/source/{id}/entrypoints` | Add entrypoint to webhook |
 | `POST` | `/source/{id}/entrypoints/{entrypointID}/delete` | Delete an entrypoint |
 | `POST` | `/source/{id}/entrypoints/{entrypointID}/toggle` | Enable or disable an entrypoint |
-| `POST` | `/source/{id}/entrypoints/{entrypointID}/secret` | Set, rotate or remove the entrypoint's inbound signature scheme and secret (see [Inbound Signature Verification](#inbound-signature-verification)) |
 | `POST` | `/source/{id}/targets`   | Add target to webhook |
 | `POST` | `/source/{id}/targets/{targetID}/delete` | Delete a target |
 | `POST` | `/source/{id}/targets/{targetID}/toggle` | Enable or disable a target |
@@ -2351,7 +2246,7 @@ webhooker/
 │   │   ├── model_setting.go   # Setting entity (key-value app config)
 │   │   ├── model_user.go      # User entity
 │   │   ├── model_webhook.go    # Webhook entity
-│   │   ├── model_entrypoint.go # Entrypoint entity and SignatureScheme enum
+│   │   ├── model_entrypoint.go # Entrypoint entity
 │   │   ├── model_target.go    # Target entity and TargetType enum
 │   │   ├── model_event.go     # Event entity (per-webhook DB)
 │   │   ├── model_delivery.go  # Delivery entity (per-webhook DB)
@@ -2413,11 +2308,9 @@ webhooker/
 │   │   ├── server.go          # Server struct, fx lifecycle, signal handling
 │   │   ├── http.go            # HTTP server setup with timeouts
 │   │   └── routes.go          # All route definitions
-│   ├── session/
-│   │   ├── session.go         # Cookie-based session management
-│   │   └── testing.go         # NewForTest: Session without the fx lifecycle
-│   └── signature/
-│       └── signature.go       # Inbound signature verification (GitHub, GitLab)
+│   └── session/
+│       ├── session.go         # Cookie-based session management
+│       └── testing.go         # NewForTest: Session without the fx lifecycle
 ├── static/
 │   ├── static.go              # //go:embed directive
 │   ├── css/input.css          # Tailwind input, source for tailwind.css (make css)
@@ -2567,15 +2460,10 @@ check, see [The login endpoint](#the-login-endpoint).
   `internal/reqtls.IsTLS` — the same predicate the session cookie uses —
   to set appropriate cookie security flags and Origin/Referer validation
   mode
-- **Optional inbound signature verification** per entrypoint (GitHub
-  `X-Hub-Signature-256`, GitLab `X-Gitlab-Token`). Off by default and
-  off after an upgrade, so behaviour is unchanged until an operator
-  turns it on. Where it is on, an unsigned or wrongly signed request
-  is `401` and is not persisted, and a configuration the receiver
-  cannot apply fails closed rather than reverting to unverified. The
-  comparison is constant time and the secret never reaches a template,
-  a JSON response or a log line (see
-  [Inbound Signature Verification](#inbound-signature-verification))
+- **The entrypoint URL is the receiver's only credential.** Nothing
+  about an inbound request is verified; possession of the UUID
+  authorises submission (see
+  [The entrypoint URL is the authentication secret](#the-entrypoint-url-is-the-authentication-secret))
 - **SSRF prevention** for HTTP delivery targets: private/reserved IP
   ranges (RFC 1918, loopback, link-local, cloud metadata) are blocked
   both at target creation time (URL validation) and at delivery time