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 every
transaction would land in one Sentry group, 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, so a request that
matched no route still reads POST /(redacted). Tracing stays off.

Model: opus-5-5

README.md

@@ -2527,10 +2527,19 @@ 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, `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 request that matched no route has no pattern, so its
+transaction keeps the SDK's name and the hook withholds it. 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
@@ -3151,7 +3160,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
@@ -3166,9 +3176,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