Carry next through the password change and let requesters pick a username

A forced or voluntary password change now redirects to the validated
`next` target (the page the user was heading for, or the home page)
instead of landing back on the account form. Login and the
must-change-password middleware pass the destination along as
/account?change=1&next=... and the form carries it as a hidden field.

The request-access form gains a required Username field validated with
the account rules and rejected when an account or another open request
already holds it (case-insensitive). Migration 0009 stores it on the
request; the notification email and the Users dashboard show it, and
the Approve form is prefilled with it.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QVPagF6jfDv78CC5Jv2wp4

README.md

@@ -205,8 +205,9 @@ from a single download menu. An
 article chapters, rate articles, and use every `/dashboard/*` page, including
 settings and jobs. Personalization is shared across accounts for now.
 
-Visitors can request an account at `/request-access`; admins review open
-requests on `/dashboard/users`. Approving a request creates a `user` account,
+Visitors can request an account with their preferred username at
+`/request-access`; admins review open requests on `/dashboard/users`. Approving
+a request creates a `user` account,
 emails a random temporary password to the requester, and marks the request
 done; the new user must choose a new password on first sign-in. Approval is
 available only when `[mail]` is active, so an account is never created with a