Name Sentry transactions after the route they matched (closes #185)

sentryhttp names each transaction after the concrete path, which the
BeforeSendTransaction hook has to withhold, so with tracing on the
transactions would fall into one Sentry group per method, such as
POST /(redacted). A middleware installed beside every sentryhttp
handler now renames the transaction to the method and chi route
pattern once the request is routed, and sets its source to route. The
hook keeps a route-sourced name and withholds every other name as
before. A path that matches nothing at the top level keeps the
withheld name; one that matches no route inside a route group, or
that the group's middleware turns away, is named after the group's
pattern, such as GET /pages/*. Tracing stays off.

Model: opus-5-5

README.md

@@ -2551,10 +2551,23 @@ Where the pattern is out of reach — the transaction dispatch, an event capture
 outside the router, or a request that matched no route — the fallback is never
 the concrete path. The path becomes the literal `/(redacted)`, so the URL reads
 `http://host/(redacted)`; a URL the rewrite cannot parse into a scheme is
-withheld whole. A transaction event additionally carries the SDK's own
-`METHOD /path` name, built from the concrete path as well; it is rewritten on
-the same terms, to `POST /h/{uuid}` where the pattern is known and
-`POST /(redacted)` where it is not.
+withheld whole.
+
+A transaction event also carries a name, which the SDK builds as `METHOD /path`
+from the concrete path and gives the transaction source `url`. Sentry groups
+transactions by name, so withholding it would put every request in the service
+into one group per method, such as `POST /(redacted)`. Inside each Sentry
+handler, a second middleware renames the transaction once the request has been
+routed, to the method and the route pattern (`POST /h/{uuid}`), and sets its
+source to `route`. The hook keeps a name whose source is `route` and rewrites
+any other to `METHOD /(redacted)`. A path that matches nothing at the top level
+has no pattern, so its transaction keeps the SDK's name and the hook withholds
+it. Inside a route group, a path that matches no route in the group, and a
+request the group's own middleware turns away before routing (a CSRF refusal,
+the redirect to `/pages/login`), are named after the group's pattern, such as
+`GET /pages/*` or `POST /hook/{sourceID}/*`, and the hook keeps that name. The
+URL on a transaction event still falls back to `http://host/(redacted)`, because
+the hook has no request there.
 
 The headers are an allowlist for the same reason the rules above are
 unconditional: the SDK's own filter removes four names and passes everything
@@ -3175,7 +3188,8 @@ Applied to all routes in this order:
 7. **Recoverer** — Panic recovery: one `ERROR` record through `internal/logger`
    and a `500`
 8. **Sentry** — Error reporting to Sentry (if `SENTRY_DSN` is set; configured
-   with `Repanic: true` so panics still reach Recoverer)
+   with `Repanic: true` so panics still reach Recoverer), and inside it the
+   naming of the request's Sentry transaction after its route pattern
 
 Recoverer sits seventh rather than first, and both neighbours are the reason. It
 runs **inside** everything that observes the response, so the `500` it writes
@@ -3190,9 +3204,9 @@ set a header or start a timer.
 
 Each admin page route group (`/pages`, `/user/*`, `/settings`, `/hooks`,
 `/hook/*`) starts with its own **Recoverer** and, if `SENTRY_DSN` is set, its
-own **Sentry** error reporting. That Recoverer answers a panic with the `500`
-error page in the normal layout; the global one keeps the plain-text `500` for
-every other route.
+own **Sentry** error reporting and transaction naming. That Recoverer answers a
+panic with the `500` error page in the normal layout; the global one keeps the
+plain-text `500` for every other route.
 
 Additionally, form endpoints (`/pages`, `/user/*`, `/settings`, `/hooks`,
 `/hook/*`) apply a **MaxBodySize** middleware that limits POST/PUT/PATCH request