Enforce the body size limit before CSRF parses the form (closes #90)

chi runs Use middleware in registration order, and every form route
group registered CSRF() before MaxBodySize(). gorilla/csrf calls
r.PostFormValue, so the form was parsed under net/http's 10 MB default
and the intended 1 MB cap never applied to form fields. The
/user/{username} group, which carries POST /password, had no
MaxBodySize registration at all.

- Register MaxBodySize ahead of CSRF in /pages, /sources, and
  /source/{sourceID}, and add it to /user/{username}.
- Reject a declared-oversize body up front with 413. Reordering alone
  cannot produce one: http.MaxBytesReader surfaces its error on Read,
  so the form parse fails and gorilla/csrf answers 403 "no token" for
  what is really an oversized body. MaxBytesReader is still installed
  afterwards so chunked or length-lying clients stay hard-capped.
- Drop the handler-local MaxBytesReader calls in auth.go, profile.go,
  and source_management.go now that the middleware is the single
  enforcement point. maxBodyShift stays; webhook.go still uses it.

The /webhook/{uuid} receiver is untouched: it bounds itself with
io.LimitReader in readWebhookBody and is neither CSRF-protected nor
form-parsed.

Tests cover the middleware in isolation (declared oversize is rejected
without reaching a sentinel handler; at-limit and under-limit bodies
pass through intact; GET is unaffected; an undeclared oversize body is
truncated at the cap) and the real router built by SetupRoutes, so the
registration order itself is guarded: an oversized POST to
/pages/login returns 413 with no gorilla/csrf cookie issued, an
oversized POST /password with a valid session and CSRF token returns
413 and leaves the stored hash unchanged, and under-limit requests
still complete through the normal CSRF path.

README.md

@@ -867,9 +867,17 @@ Applied to all routes in this order:
 8. **Sentry** — Error reporting to Sentry (if `SENTRY_DSN` is set;
    configured with `Repanic: true` so panics still reach Recoverer)
 
-Additionally, form endpoints (`/pages`, `/sources`, `/source/*`) apply a
-**MaxBodySize** middleware that limits POST/PUT/PATCH request bodies to
-1 MB using `http.MaxBytesReader`, preventing oversized form submissions.
+Additionally, form endpoints (`/pages`, `/user/*`, `/sources`,
+`/source/*`) apply a **MaxBodySize** middleware that limits
+POST/PUT/PATCH request bodies to 1 MB. It is registered ahead of the
+CSRF middleware in every one of those route groups, because
+gorilla/csrf parses the form; if the cap were installed after it, form
+parsing would run under net/http's 10 MB default and the 1 MB limit
+would never apply. A request that declares a `Content-Length` over the
+limit is answered with `413 Request Entity Too Large` before any other
+middleware or handler runs; a chunked request, or one that lies about
+its length, is hard-capped by `http.MaxBytesReader` and fails
+downstream at form-parse time.
 
 ### Authentication
 
@@ -891,7 +899,8 @@ Additionally, form endpoints (`/pages`, `/sources`, `/source/*`) apply a
 - Production security headers on all responses: HSTS, X-Content-Type-Options
   (`nosniff`), X-Frame-Options (`DENY`), Content-Security-Policy, Referrer-Policy,
   and Permissions-Policy
-- Request body size limits (1 MB) on all form POST endpoints
+- Request body size limits (1 MB) on all form POST endpoints, enforced
+  by middleware that runs before CSRF parses the form
 - **CSRF protection** via [gorilla/csrf](https://github.com/gorilla/csrf)
   on all state-changing forms (cookie-based double-submit tokens with
   HMAC authentication). Applied to `/pages`, `/sources`, `/source`, and