fix(cdn): RRO stub blob carries the room's own game-role objects

Enable + co-owner still gave no Maker Pen. The 2023 client grants Maker
Pen / save / spawn rights off the player's GameRole
(ICreatorRole.CreatorRoleCanUseMakerPen on RecRoom.Systems.PlayerRoles
.GameRole), and game roles are persisted OBJECTS in the room blob: every
real save inspected (Rec Center room_100_v1.dat, Stunt Runner
room_125_v1.dat) carries three GameRoleNode chips — a default role named
after the room plus the built-in "In-Game" and "Eliminated" roles, with
well-known GUIDs shared by every room. A blob with none leaves a co-owner
with no role to hold, so MakerPen.CheckMakerPenPermissionAndUpdateMode
fails regardless of the room-role collection.

BuildRroEditableBlob now emits Rec Royale's own three role objects, laid
out field-for-field like the client's writer (including the always-present
empty Overridable submessages), with view ids derived from the activity id
so repeated downloads describe the same objects. The default role sets
can_use_maker_pen, matching the permissive room-role overlay. Test pins
three persistence views and the three role GUIDs.

DorkNet.Server/Controllers/Cdn/CdnController.cs

@@ -568,7 +568,7 @@ public class CdnController(
             // Maker Pen. See RoomDataBlobService.BuildRroEditableBlob.
             logger.LogInformation("[cdn] MISS host={Host} file={File} -> RRO editable blob (room {Room}, activity {Activity})",
                 Request.Host.Host, fileName, rroRoom.Id, rroRoom.LocationReplicationId);
-            var rroBlob = roomDataBlob.GetRroEditableBlob(rroRoom.LocationReplicationId);
+            var rroBlob = roomDataBlob.GetRroEditableBlob(rroRoom.LocationReplicationId, rroRoom.Name);
             rroBlob = ClampForClientUnlessDisabled(rroBlob, fileName);
             Response.Headers.CacheControl = "public, max-age=60";
             signatures.AddContentSignature(Response, rroBlob);