Summary

Closes #24. The registration endpoint only validated username length, so an email address like user@example.com was accepted as a username. Because login looks users up by username (a public identifier), allowing emails is confusing and undesirable.

What changed

• Added a validate_username helper in src/routes/auth.rs that:
  • Rejects any username containing @ → 400 "username may not be an email address"
  • Restricts the charset to lowercase [a-z0-9_.]
  • Forbids leading/trailing .
• Wired it into register() after the existing length check.
• Applied the same rule to the username-update endpoint update_current_user() in src/routes/users.rs (as suggested in the issue).
• Added tests in tests/e2e.rs covering email-shaped usernames and invalid charsets (uppercase, spaces, leading/trailing dots).

Reviewer notes

• Length validation (1–32 chars) is unchanged and remains in the callers; the new helper only handles charset/format.
• Validation runs at registration and username-update time only — it does not affect login lookups, so pre-existing nonconforming usernames continue to work.

Test plan

• cargo test --test e2e register — all 6 register tests pass (including 2 new ones)
• cargo check clean