Webpage Integration: Username Validation 1

## Goal

Enforce username uniqueness at the database level, case-insensitively, cap username length, and protect reserved and notable identities from being claimed.

---

## Background

`display_name` is wired into contributor identity matching, git commit author attribution, and public-facing profile surfaces. The current uniqueness check is form-level only, which leaves a race condition between validation and save, and nothing prevents the same name being claimed twice under different capitalization.

---

## Requirements

### 1. Uniqueness and character limit

**Uniqueness**

- Usernames are unique, case-insensitively. Capitalization does not create a new username — `Jeremy`, `jeremy`, and `JEREMY` are the same value and only one account can hold it.
- When a requested username is unavailable, the error says so without naming or confirming the account that holds it.

**Character limit**

- Maximum 15 characters

**Migration**

- Existing usernames need auditing for case-insensitive duplicates and for values over 15 characters before the constraint is applied. The constraint will fail to build if either exists.
- Resolution approach for any found needs a decision — see open questions
- If we can leave existing contradictions and apply to only new usernames, I'll recommend we go this route.
### 2. Reserved and protected names

Both of the following mechanisms are implemented together:

**Auto-protection from author/maintainer records**

- Any username that matches the name of a flagged author or maintainer cannot be claimed by a different account.

**Reserved-name table**

- A new admin-managed reserved-name table is introduced to cover names with no existing account (e.g. notable or deceased founders) and any name that should be blocked for other reasons.
- Each entry in the table supports an optional `allowed_user` field, so the legitimate owner of a protected name can be granted the right to claim it without requiring a migration.
- Reserved-name matching uses the same canonical normalization as uniqueness enforcement.
- When a name is refused due to the reserved-name table, display the error message below:

Unavailable:

> That username is on the reserved names list. Usernames aren't case-sensitive, so changing capitalization won't help — try a different username.

---

## Copy

Unavailable:

> That username isn't available. Usernames aren't case-sensitive, so changing capitalization won't help — try a different username.

Over the character limit:

> Usernames can be up to 15 characters. .

The case-insensitivity clause is load-bearing. Without it, a user who finds `jeremy` taken tries `Jeremy` next and reads the second rejection as a bug.

---

## Acceptance criteria

- Two accounts cannot hold the same username in different cases; the attempt is rejected at the database level, not only by the form
- Concurrent submissions of the same username result in one success and one rejection
- A username over 15 characters is rejected with the character-limit message
- The unavailable message appears without disclosing the account holding the name
- Existing usernames pass the audit, or have been resolved, before the constraint is applied
---

## Out of scope

- Confusable and permutation detection
- Rate limiting username changes
- Frontend work beyond surfacing the messages above
---

## Open questions

- How are existing case-insensitive duplicates resolved — first-registered keeps it, most-active keeps it, or manual review?
- Are existing usernames over 15 characters grandfathered, or forced to change on next login?

No files, tests, or entry points are named in the issue. Start by locating the username model, current form-level uniqueness validation, and migration setup; resolve the duplicate and overlength policy questions before implementation, then verify the concurrency, audit, validation, reserved-name, and message acceptance criteria.

Written by the indexing model from the issue text.