add game engine openapi

ARCHITECTURE.md

@@ -579,7 +579,7 @@ Minimum runtime-level status set:
 All game-related `message_type` include `game_id`.
 
 Gateway enriches them with authenticated `user_id` and routes them to `Game Master`.
-`Game Master` checks whether this user may access this running game, using membership data sourced from `Game Lobby`, then routes the command to the correct engine container.
+`Game Master` checks whether this user may access this running game, using membership data sourced from `Game Lobby`, then routes the command to the correct engine container using [Game Engine](./game/README.md)'s API.
 
 The gateway never routes directly to game engine containers.
 
@@ -649,7 +649,7 @@ After a game has started, two different actions exist:
 
 This distinction is architectural and must remain explicit.
 
-## 9. Runtime Manager
+## 9. [Runtime Manager](rtmanager/README.md)
 
 `Runtime Manager` is the only internal service allowed to access Docker API directly.
 
@@ -1275,11 +1275,11 @@ Recommended order for implementation is:
 4. **Mail Service** (implemented)  
    Internal email delivery for auth codes and platform notification mail.
 
-5. **Notification Service** (implemented)
+5. **Notification Service** (implemented)  
    Unified async delivery of push and non-auth email notifications, with
    real Gateway and Mail Service boundary coverage.
 
-6. **Game Lobby Service**  
+6. **Game Lobby Service** (implemented)  
    Platform game records, membership, invites, applications, approvals, schedules, user-facing lists, pre-start lifecycle.
 
 7. **Runtime Manager**