Read telemetry names from running dedicated config; record Workshop 0.0.138

docs/telemetry.md

@@ -256,8 +256,9 @@ update and receipt index migration; it does not require a new mission release.
 
 ### Automatic server names
 
-New events resolve the reporting server’s name from `ServerLobbyApi.GetServerConfig().GetName()`,
-falling back to lobby metadata if unavailable. The optional profile `serverName`
+New events first read `game.name` from `BackendApi.GetRunningDSConfig()`.
+If unavailable or blank, they try `ServerLobbyApi.GetServerConfig().GetName()`
+and then `GetGame().GetServerInfo().GetName()`. The optional profile `serverName`
 remains an explicit override. Names are trimmed and bounded to 120 characters.
 Resolution repeats for each new event so startup metadata delays do not permanently
 leave a server unnamed. Neither scenario titles nor account identities are used.
@@ -277,3 +278,9 @@ explicit override and absent-metadata fallback pass without script failures; the
 13 inherited resource/world errors remain. The local Workbench fixture has no
 configured server name, so the real dedicated-server name must still be confirmed
 from the first report after publishing.
+
+Dedicated-name follow-up: [validation evidence](evidence/telemetry-dedicated-name-2026-11-01/verification.json)
+records the added `GetRunningDSConfig().game.name` priority path. Production-method
+tests cover dedicated names and fallback conditions; native Workbench compilation
+and available-metadata checks pass. Workbench still has no running dedicated
+configuration, so this does not prove recovery on a live dedicated server.