Read form fields from the POST body only (closes #160)

r.FormValue falls back to the query string, so
POST /source/{id}/targets?url=<secret> created a working target from a
value carried on the request line — where proxy logs, browser history
and Referer all record it. Every form read is now r.PostFormValue,
including the login password and both password-change fields, which had
the same defect in a more acute form.

The Sentry leg needed more than the query string. sentryhttp attaches
the whole request to the scope, and ApplyToEvent copies the teed body
into Request.Data with no SendDefaultPII guard — so reading every field
from the body only pointed every credential this change protects at the
one field the first revision did not scrub. Body and query are now
redacted, Cookies and Env cleared, and Headers reduced to an allowlist,
because the SDK's own filter removes four names and would otherwise ship
X-Csrf-Token and the shared secrets senders put on the receiver route.

Also adds json:"-" to Target.Config, APIKey.Key and Setting.Value —
TargetView is the masking barrier for the HTML path only, and the first
handler to marshal a model would serialise a bearer token or the session
encryption key.

Independently reviewed three times. The second review found the Data
leak and proved it with a scratch module; the third disproved the
PR's own claim that BeforeSend gets no request, so the README now
records that redacting unconditionally is a deliberate choice rather
than a limitation — which is what makes #179 cheap to fix.

README.md

@@ -1025,6 +1025,53 @@ buy the same amplification as an invented path. Nothing debuggable is
 lost: `page`, on the authenticated pagination links, is the only query
 parameter this service reads.
 
+Client-supplied request content does not leave the host by the other
+route either. The Sentry SDK attaches the request to every event it
+captures, independently of the access log, and `SendDefaultPII=false`
+does not cover all of what it copies: the raw query string and the
+first 10 KiB of the request body are both taken unconditionally, the
+body precisely because these handlers call `ParseForm`. A `BeforeSend`
+hook therefore replaces the query string and the body with
+`(redacted)`, drops cookies and the remote-address environment, and
+reduces the headers to a fixed allowlist — `Accept`, `Content-Length`,
+`Content-Type`, `Host`, `Origin`, `Referer`, `User-Agent` and
+`X-Request-Id`.
+
+The body is replaced on every route rather than filtered by route, and
+that is a choice rather than a limitation: the route is reachable from
+the hook. `sentryhttp`'s recover path puts the request on the context
+it hands to `RecoverWithContext`, and the SDK carries that context
+through to `BeforeSend` as `hint.Context`, so
+`hint.Context.Value(sentry.RequestContextKey)` yields the live request
+and chi's `RoutePattern()` yields the matched pattern off it. There
+are two reasons to redact unconditionally anyway. Nothing debuggable
+is lost:
+every handler reads its fields with `PostFormValue`, so the body is
+exactly where the credentials are — the target destination URL, the
+login password, both password-change fields — and the one route whose
+body is genuine signal is the receiver, whose body is already stored
+on the event and served from the UI, so a tracker is not where anyone
+reads it. And an unconditional rule cannot leak on a route somebody
+forgets to add to it, which a route-conditional one can.
+
+The headers are an allowlist for that second reason: the SDK's own
+filter removes four names and passes everything else, which would ship
+`X-CSRF-Token` and the shared secrets senders put on the receiver
+route. What survives still names the failing route — scheme, host,
+path, method — and `X-Request-Id` ties the event to the local access
+log line that holds the rest. Nothing dropped is needed for the
+likeliest use, debugging a CSRF rejection. Its three inputs are the
+TLS decision, `Origin` and `Referer`; the latter two are kept, and the
+first is already in the retained URL, because the SDK derives that
+URL's scheme from `r.TLS != nil || r.Header.Get("X-Forwarded-Proto") == "https"` —
+byte for byte the predicate `internal/middleware/csrf.go` uses to
+choose between the `csrf.Secure(true)` and `csrf.Secure(false)`
+handlers. So dropping `X-Forwarded-Proto` costs nothing. The dropped
+provider headers (`X-GitHub-Event`, `X-Gitlab-Event` and the like) are
+real signal but are recorded locally on the event, and
+`Sentry-Trace`/`Baggage` are already reflected in the event's trace
+context.
+
 The remaining client-supplied fields are truncated rather than dropped,
 each to a fixed budget: 512 bytes for `url`, `useragent` and `referer`,
 128 for `request_id` (chi passes an inbound `X-Request-Id` header