fix(account): /account/update_name validates name input

Reject empty / whitespace / explicit-null / over-cap names with 400
instead of NREing on null assignment or storing arbitrarily-long
strings the DB column has no cap on. 24-char limit is a conservative
backstop against direct API abuse; the client UI enforces its own
keyboard limit.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

SVSim.EmulatedEntrypoint/Controllers/AccountController.cs

@@ -10,6 +10,14 @@ namespace SVSim.EmulatedEntrypoint.Controllers;
 /// </summary>
 public class AccountController : SVSimController
 {
+    /// <summary>
+    /// Conservative server-side cap on viewer display names. The client's UserNameInput
+    /// enforces its own limit at the keyboard; this is the backstop against direct API
+    /// abuse (10-MB names ballooning every subsequent /load/index, etc.). Names are
+    /// typically &lt;=20 chars in prod traffic.
+    /// </summary>
+    private const int MaxDisplayNameLength = 24;
+
     private readonly SVSimDbContext _db;
 
     public AccountController(SVSimDbContext db)
@@ -22,6 +30,14 @@ public class AccountController : SVSimController
     {
         if (!TryGetViewerId(out long viewerId)) return Unauthorized();
 
+        // Defensive null check: the DTO defaults to string.Empty but a JSON body with
+        // an explicit `"name": null` deserialises through msgpack→JSON→STJ to null, and
+        // assigning null to viewer.DisplayName (non-nullable in the entity) would NRE.
+        if (string.IsNullOrWhiteSpace(request.Name))
+            return BadRequest(new { error = "name_empty" });
+        if (request.Name.Length > MaxDisplayNameLength)
+            return BadRequest(new { error = "name_too_long" });
+
         var viewer = await _db.Viewers.FirstAsync(v => v.Id == viewerId);
         viewer.DisplayName = request.Name;
         await _db.SaveChangesAsync();