Merge branch 'fix/username-resolve-floor'

MinCollectibleUsernameLength doubles as the resolve-time floor for every
username kind (contacts.resolveUsername, the public web landing page),
not just collectible minting. It was still 4 after the admin write path
was lowered to 3, so an operator-assigned 3-character username could be
set but never actually resolved by anyone. Match the two floors.

internal/domain/collectible_username.go

@@ -15,12 +15,18 @@ import (
 // the same global registry, so occupancy checks and username resolution have a
 // single source of truth.
 //
-// The editable slot keeps the service-level 5..32 length rule. Collectible names
-// are minted by the operator and may be shorter: short names are precisely what
-// a collectible market distributes. They still have to be syntactically
-// resolvable by clients, so the character rules are identical.
+// The editable slot keeps the service-level 5..32 length rule for
+// self-service (account.updateUsername / channels.updateUsername); the admin
+// path can go as low as 3 (see users.minUsernameLenAdmin /
+// channels.minChannelUsernameLenAdmin). Collectible names are minted by the
+// operator and may be shorter: short names are precisely what a collectible
+// market distributes. Every kind of username still has to be syntactically
+// resolvable by clients (contacts.resolveUsername, the public web landing
+// page), so this floor doubles as the resolvability floor for the whole
+// registry -- it must stay <= the lowest floor any write path can produce,
+// currently 3.
 const (
-	MinCollectibleUsernameLength = 4
+	MinCollectibleUsernameLength = 3
 	MaxCollectibleUsernameLength = 32
 	// MaxPeerCollectibleUsernames bounds the collectible rows a single peer can
 	// hold. The TL usernames vector is rendered in full by clients, so the bound