fix: improve dashboard and lifecycle

Docs/LinuxDeploymentAndUpdates.md

@@ -127,6 +127,21 @@ they differ, Quasar warns that a manual server restart is required. It does not
 auto-schedule that restart; the operator-triggered stop/start path runs launch
 preparation and injects the bundled deployable DLL before relaunch.
 
+## Managed Runtime Update Checks
+
+The Updates page always shows the currently installed Quasar, Bootstrap,
+Magnetar, and Space Engineers Dedicated Server versions when Quasar can resolve
+them from release metadata or executable file versions. It also shows the
+managed runtime install paths and the most recent managed-runtime check time.
+
+Quasar UI worker and Bootstrap checks use the Quasar release checker interval
+(15 minutes by default) and the page's **Check Quasar** button. Managed Magnetar
+checks run during startup readiness and then every hour while Quasar is running;
+the page's **Check Magnetar** button runs the same check immediately. Managed DS
+checks run during startup readiness; **Check Dedicated Server** runs SteamCMD
+`app_update 298740 validate` immediately so an operator does not need to wait
+for a restart to verify or refresh the DS install.
+
 ## Bootstrap Updates
 
 Bootstrap checks the primary Quasar release stream every 15 minutes by default.

Docs/QuasarArchitecture.md

@@ -328,7 +328,8 @@ Quasar should behave like infrastructure/configuration management:
 - if goal state is `On` and the server crashes, Quasar restarts it according to policy
 - if goal state is `On` and the server is unhealthy, Quasar evaluates the health policy and recovers it automatically where configured
 - if goal state is `Off` and the server is running, Quasar stops it
-- if an admin stops the server from in-game (Magnetar `!quit` or Quasar Agent `!stop`), the agent reports the shutdown intent and Quasar sets goal state to `Off`, so the server stays stopped instead of being treated as a crash and restarted
+- if an admin stops the server from in-game with Quasar Agent `!stop` or `!quit`, the agent reports `AdminStop` and Quasar sets goal state to `Off`, so the server stays stopped instead of being treated as a crash and restarted; `!stop` saves first, while `!quit` exits immediately without saving
+- if an admin restarts the server from in-game with Quasar Agent `!restart`, the agent reports `AdminRestart`, Quasar keeps goal state `On`, records process state `Restarting`, and relaunches the server after the save-and-quit exit instead of waiting for a reconnect that will never arrive
 - operator actions should usually mutate goal state first, then let reconciliation perform the transition
 
 This should be treated more like Terraform or other IaC reconciliation than like a passive dashboard.
@@ -540,6 +541,15 @@ request file under `Updates/` containing the detected version and asset;
 Bootstrap consumes it with a watcher and runs the same checksum-verified
 self-update path for that requested release immediately.
 
+The Updates page also shows installed managed-runtime versions independently of
+Quasar self-update state: Quasar UI/Bootstrap, Magnetar, and the Space Engineers
+Dedicated Server can all be inspected there. Quasar release checks run on the
+configured update interval (15 minutes by default) and can be triggered by the
+Quasar check button. Managed Magnetar is checked on startup and every hour after
+startup, with a separate manual Magnetar check button. The managed Dedicated
+Server is checked during startup readiness and can be forced through its own
+manual check button; the action runs SteamCMD `app_update 298740 validate`.
+
 ### Future proxy update flow
 
 1. download or place a new Quasar release into a staged version directory
@@ -859,6 +869,10 @@ As of this document:
 - per-server managed .NET runtime selection now exists on Windows, where Quasar installs both Magnetar builds side-by-side (`MagnetarInterim.exe` on .NET 10, the default, and `MagnetarLegacy.exe` on .NET Framework 4.8) and the runtime resolver launches the build chosen by `DedicatedServerDefinition.ManagedRuntime`; non-Windows hosts always run the .NET 10 build
 - runtime config preparation now derives a unique `SteamPort` (`ServerPort + 1000`) and `RemoteApiPort` (`ServerPort + 2000`) per server so multiple servers co-hosted on one machine never collide on the SE defaults (8766 / 8080)
 - server naming across the UI now consistently prefers the operator-configured `DedicatedServerDefinition.DisplayName` over the agent's in-game `ConfigDedicated.ServerName` (the analytics filters/legends, Discord per-server panels, the entities/plugins server selectors, the players list, and the plugin log panel all resolve names this way, falling back to the live agent name and then the unique name)
+- Dashboard server view selection now persists in browser local storage while still accepting `?view=list` / `?view=cards` overrides; card and list layouts use the same catalog order by unique name. Dashboard cards expose the assigned config profile as an actionable chip, the server port as a direct-connect copy chip (`host:port`), and the same create-server entry point the list layout already had.
+- Quasar Agent now owns in-game `!stop`, `!restart`, and `!quit` semantics for managed servers: `!stop` saves and turns the Quasar goal Off, `!restart` saves and lets Quasar track/relaunch the Restarting state, and `!quit` exits without saving while turning the goal Off.
+- startup version logging now records Quasar worker version in the Quasar log and Magnetar/Quasar.Agent version details in the Magnetar-side log path.
+- the Updates page now always surfaces installed managed Magnetar and Space Engineers Dedicated Server versions/paths beside Quasar version data, and exposes separate manual update checks for Magnetar and DS. Magnetar checks continue hourly after startup; DS checks run at startup and on explicit request.
 - the Analytics dashboard renders metrics as client-side uPlot canvas charts: the browser fetches compact, timeline-aligned series from a JSON HTTP endpoint (`/api/analytics/series`, backed by `AnalyticsSeriesService`, which selects the RRD consolidation tier by span — raw ≤2h, 1-minute ≤24h, 1-hour beyond — and drops empty buckets); profiler game-loop timing buckets (frame, update, physics, scripts, network, other) and extensive profiler top grids/entity types are surfaced as additional chart panels through the same endpoint via `ProfilerAnalyticsMetrics` and `ProfilerEntryAnalyticsMetrics`; the same page edits each server/agent profiler mode with user-facing labels ("Simple, low overhead" for `SafeContinuous`, "Extensive, deep detail" for `DeepContinuous`) and pushes live changes through `ServerCommandType.SetProfilerMode`; the previous inline `ProfilerSummaryCard` tables and the `blocks`/`floating-objects` scalar metrics have been removed
 - deep per-server profiler telemetry now exists: `Quasar.Agent` runs a continuous in-process profiler with `SafeContinuous` enabled by default, with per-server persisted `AgentProfilerMode` values and a global `Quasar:AgentProfilerMode` / `QUASAR_AGENT_PROFILER_MODE` fallback for older definitions. Safe mode uses Harmony prefix/postfix timing only for named high-level paths: frame/update, programmable-block script, physics, replication/network/session, GPS, and block-limit work. It deliberately avoids broad entity update method patching and detailed network-event hooks so the always-on default stays low overhead. Deep mode adds detailed network-event method hooks plus Magnetar-compatible Harmony IL call-site transpilers for `MySession.Update` / `UpdateComponents`, session component calls, replication simulation, entity update dispatch, parallel waits/callbacks, and Havok physics stepping internals. Runtime mode changes reconfigure Harmony patches so Safe, Deep, and Off can be selected without restarting the server. Hot-path measurements use numeric call-site ids and rolling accumulators, split main-thread vs off-thread time, and publish one-second windows with bounded top-lists for grids, scripts, entity types, system methods, physics detail, and network/replication/session work where the active patch depth can observe them. Patch failures are logged and the agent keeps the remaining profiler surface; entity call-site misses stay at high-level timing rather than adding broad method wrapping. Each `ProfilerSnapshot` rides the regular agent snapshot, is validated, and is kept in a small recent in-memory `ProfilerStoreService` ring (~720 samples per server, about 12 minutes at one snapshot per second), then surfaced on the Analytics page as game-loop timing and top grid/entity-type chart panels
 - Discord per-server options now include chat relay and simspeed alert rules. Discord-to-game chat is injected as `[Discord] <username>: <message>` so in-game readers see the Discord sender, and `DiscordChatRelayService` suppresses the matching game-history echo before it can post back to Discord as the server/bot author. `DiscordSimSpeedAlertService` evaluates fresh raw metric samples for connected/running agents on the registry change path, sending alerts through the configured simspeed channel or the server's analytics channel. Baseline rules detect sharp sample-to-sample drops across every unseen raw sample pair and sustained low average simspeed, and the Discord page exposes thresholds, windows, cooldowns, and per-rule enable switches. `DiscordBotService` also publishes aggregate managed-server state through Discord presence: the bot status reflects unhealthy/faulted vs active vs idle server instances, and its activity text shows active/total servers, player count, and issue/warning counts.