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.

docs/admin.md

@@ -222,7 +222,16 @@ actions:
   `LocationReplicationId`, `last_save_time`, empty connectable graph /
   object model, scene settings and the four `room_mood_*` blocks, plus the
   permissive role collection. The miss path now runs the same 2023
-  version clamp as the S3-hit path.
+  version clamp as the S3-hit path. It also carries the room's own three
+  **game-role objects** (a default role named after the room, plus the
+  built-in "In-Game" and "Eliminated" roles, well-known GUIDs shared by
+  every room save — Rec Center and Stunt Runner both have exactly these).
+  The 2023 client grants Maker Pen off the player's *game* role
+  (`ICreatorRole.CreatorRoleCanUseMakerPen` on `GameRole`), so a blob with
+  no role objects leaves even a co-owner with nothing to hold — that was
+  the second reason "enable + co-owner" still showed no Maker Pen. The
+  default role sets `can_use_maker_pen` to true, matching the permissive
+  room-role overlay; the built-in roles mirror the reference saves.
 - **Reset to baked scene** — `POST api/admin/v1/rooms/{id}/subrooms/{subRoomId}/blob/reset`.
   Clears both pointers. This is the escape hatch if a save left the room
   unplayable. Saved blobs stay in `RoomDataBlobs`, so the in-game restore

docs/recroom-2023-room-save.md

@@ -163,6 +163,17 @@ LocationReplicationId, connectable graph, scene settings, object model,
 `room_mood_*`). `RoomDataBlobService.BuildRroEditableBlob` now emits that
 skeleton per room at version 16.
 
+Second requirement — game-role objects. Both reference saves carry three
+`PersistenceViewData` entries whose `game_role_node_data` (field 50) holds a
+`PlayerGameRoleData`: the room's default role (Rec Center: "Rec Center",
+Stunt Runner: "StuntRunner"; GUID `c48bac02-…` in both), "In-Game"
+(`role_id` 2097152, GUID `2c721342-…`) and "Eliminated" (`role_id`
+4194304, rank 1015, `can_move` false, GUID `0b9ec39e-…`). Their
+`spawnable_tool_data.prefab_id` is the GameRoleNode chip prefab
+(`c46e1535…` raw). Since 2023 permissions hang off the player's GameRole,
+a blob without these leaves a co-owner with no Maker Pen. The stub now
+generates Rec Royale's own set (view ids derived from the activity id).
+
 Admin switch: `POST api/admin/v1/rooms/{id}/subrooms/{sub}/blob/enable`
 stamps `RoomService.SyntheticDefaultRoomDataBlobName(id)` on the scene and
 room; `.../blob/reset` clears it. See `docs/admin.md` → "RRO room data