Add optional display username for dashboard users

[Macnelson9]

Why

The dashboard greeting currently falls back to the email address for a display name (e.g. showing the raw local-part of an email like `lateeftosin1999`), which reads as an account handle rather than a name. There was no way for a user to set an actual display name, and no field to carry one.

What changed

• Added a nullable, case-insensitively-unique `username` column on `users`.
• Threaded `username` through every response that returns a user (signup verification, login, refresh, `GET /v1/auth/me`).
• Added `PATCH /v1/auth/me` to set the username, with validation (3–20 chars, `[a-zA-Z0-9_-]` only) and a 400 on a case-insensitive duplicate.
• Updated a migration-count test that hardcoded the list of known migrations.

Where

• `crates/store/migrations/0020_username.sql` — new migration (column + unique index)
• `crates/store/src/models.rs` — `User.username`
• `crates/store/src/lib.rs` — `update_username` store method
• `crates/api/src/auth.rs` — `UserView.username`, `PATCH /v1/auth/me` handler, validation
• `crates/api/src/lib.rs` — route wiring
• `crates/store/tests/store_tests.rs` — updated expected migration set

Solution

Kept the write path minimal and separate from account creation: username stays `null` until a user explicitly sets one via the new `PATCH` endpoint, so existing accounts are unaffected. Uniqueness is enforced at the database level (case-insensitive unique index) rather than only in application code, so it holds even under concurrent requests. Verified locally against a real Postgres instance: migration applies cleanly, `fmt`/`clippy`/`cargo test --workspace` all pass, and the endpoint was exercised end-to-end (set username, fetch it back, and confirm a case-insensitive duplicate is rejected).

This is a companion to the Octo-frontend PR that adds the dashboard UI (greeting + Settings page) consuming this endpoint.