Release LoadGen Api, Appliance and MCP Server: 1.0.0.11878

LoadGen General

• Picked up every available Debian security backport during the build of the API and MCP container images, keeping the base layer current and future-proofing against the next round of backports.

LoadGen Api

• [#8639] Wired the managed-PostgreSQL contract end-to-end for the upcoming LG058 Service Levels (SLO/SLA) storage. The appliance management surface gains operations to report PostgreSQL status (container running state and version), discover an existing setup, provision the service, and manage its credentials, plus a new postgreSqlEnabled field on the service-status / set-service-status payloads. Status reporting is fully implemented; the remaining operations currently return a clear "schema-provisioning ships with LG058" message, with the full implementation landing with LG058.
• [#8595] The API now reports the API, appliance-agent and MCP versions together in a single slim diagnostics response, so the Frontend can pass all four versions (appliance, API, MCP, frontend) to the LoadGen notifications service for server-side targeting filters. The MCP version is determined once at API startup; when it cannot be obtained (MCP unreachable, stdio-only deployment) it is reported as null and the upstream service treats it as a wildcard.
• [#8595] New per-user notification read-state store on the appliance, keeping user-identifiable interaction state on the appliance instead of LoadGen-hosted infrastructure. Read state (including bulk updates) is strictly private to each user and lives with the rest of that user's state on the appliance.
• [#8565] New aggregated runningTestCount field on GET /v1/appliance/system/status correctly sums load-test execution and in-progress end-to-end monitoring sessions (uptime checks are deliberately excluded). The legacy testsRunning boolean is retained as runningTestCount > 0 for existing consumers. safeToReboot semantics are unchanged (still load-test-only) — a running monitoring workload does not block reboot because monitoring sessions resume cleanly across reboots.
• [#8635] / [#8636] Hardened the Web / Core load-profile endpoints. POST /v1/config/load-profiles now returns the saved, normalized bundle so callers receive the server-assigned profile ID and normalized assignment arrays. Web / Core POST and PUT reject empty-GUID and unknown web-user IDs with 400 before corrupt rows can be persisted; GET /v1/config/load-profiles/{name}/complete now resolves Web / Core assigned users from the profile bundle and ignores already-corrupt empty rows on read.
• [#8628] Fixed the SessionSight heatmap page list reporting 0 total and "no heatmaps available" when many single-count clicks at distinct coordinates were present on a page: the minimum-interactions threshold is now applied to per-page totals rather than to individual points, so pages with many low-count interactions surface correctly. Added structured SessionSight troubleshooting logging across the processing pipeline so future support bundles show where data disappeared, without logging payload bodies.

LoadGen Appliance

• [#8639] Added the managed-PostgreSQL service for the new Service Levels capability. The agent's compose template gains an optional PostgreSQL 17 service (container loadgen-postgres) that is reachable only locally on the appliance and never exposed through the appliance's web proxy. The PostgreSQL bootstrap password is resolved automatically, so deployed appliances never see a literal secret. The Compose Migration card naturally reports the new service missing on existing appliances; first-boot of a fresh appliance ships with the service in place, disabled by default. Data directories are prepared with the correct ownership when the service is enabled, so the container starts cleanly, and its logs are available through the standard appliance log retrieval once the container runs.

LoadGen MCP Server

• [#8595] The MCP Server now reports its version over the HTTP transport, feeding the slim version diagnostics consumed by the Frontend's notification targeting. HTTP-mode only: stdio-only deployments intentionally have no equivalent, in which case the API reports the MCP version as null.