feat: runtime manager

lobby/docs/runbook.md

@@ -35,8 +35,11 @@ Before starting the process, confirm:
   - `LOBBY_USER_LIFECYCLE_STREAM` (default `user:lifecycle_events`)
   - `LOBBY_NOTIFICATION_INTENTS_STREAM` (default `notification:intents`)
 - `LOBBY_RACE_NAME_DIRECTORY_BACKEND` is `postgres` for production
-  (the default after PG_PLAN.md §6B); the `stub` value is only for
-  unit tests that do not need a real PostgreSQL.
+  (the default after PG_PLAN.md §6B); the `stub` value selects the
+  in-memory adapter at `lobby/internal/adapters/racenameinmem/`,
+  intended for unit tests and small local deployments without
+  PostgreSQL. The config token name is kept as `stub` for backward
+  compatibility.
 
 At startup the process opens the PostgreSQL pool, applies migrations,
 pings PostgreSQL, then opens the Redis client and pings Redis. Startup

lobby/docs/runtime.md

@@ -161,8 +161,11 @@ The groups below summarize the structure:
 - `Game Lobby` owns platform game state. Game Master may cache snapshots but
   is not the source of truth.
 - The Race Name Directory ships a PostgreSQL adapter (default after
-  PG_PLAN.md §6B) and an in-process stub. The stub is intended for unit
-  tests and is selected via `LOBBY_RACE_NAME_DIRECTORY_BACKEND=stub`.
+  PG_PLAN.md §6B) and an in-process implementation in
+  `lobby/internal/adapters/racenameinmem/`. The in-memory backend is
+  intended for unit tests and small local deployments and is selected
+  via `LOBBY_RACE_NAME_DIRECTORY_BACKEND=stub` (the config token name
+  is preserved for backward compatibility).
 - A `permanent_block` or `deleted` event from User Service fans out
   asynchronously through the `user:lifecycle_events` consumer; in-flight
   games owned by the affected user receive a stop-job and transition to