[#8791] Create Repository and Invite Machine from the Repositories page — In Master mode, the Repositories page now has a + Create Repository button in the header and a + Invite Machine action on each repository row, so administrators no longer need Swagger or curl to obtain a Master API key. Both flows open a guided modal (Repository ID, Name, Machine ID, description, environment, region, customer, optional Master API URL override) and finish with a one-time API key reveal panel: amber "this key will be shown only once" warning, monospaced read-only key field, copy-to-clipboard button with a 2-second confirmation, and the Repository ID and Master API URL printed alongside so the full triple can be handed straight to the slave appliance. The reveal panel deliberately blocks backdrop-click and escape dismissal — the only way out is the explicit I have copied the key button — so an unrecoverable key cannot be lost by accident. The Repositories page "How to Configure" panel and master-side empty-state text also now say API key instead of the misleading word credentials, and tell operators that their administrator generates the key from the master appliance's + Create Repository button, closing the discoverability loop.
[#8792] Docker tab "Initialized: No" rows now link to the Services tab — On the Docker tab of the Appliance page, the InfluxDB and PostgreSQL container cards' Initialized row, and the Grafana card's Datasources row, now render as an inline No · Configure in Services → link (or 0 · Configure in Services → for Grafana) whenever the service is not yet initialized or has zero datasources. The link jumps straight to the matching card on the Services tab and lands with the sticky header cleared, so an operator who just enabled PostgreSQL, Grafana, or InfluxDB has an obvious next step instead of a dead-end Initialized: No value. Once a service is initialized, the row reverts to the static Yes or numeric count it always was.
[#8793] PostgreSQL setup errors now stay inside the Setup modal — Failures from the PostgreSQL setup flow on the Services page no longer leak onto the background page as a full-width red banner. Errors are now shown inline inside the Setup PostgreSQL modal itself (matching the pattern already used by the sibling Change Credentials modal), are cleared when the modal is reopened or dismissed, and the page-level status banner is left alone on failure. The known "not yet implemented" stub message is also rewritten to a customer-safe variant — "PostgreSQL setup is not yet implemented on this appliance. The provisioning feature ships in a future update." — so internal documentation references never reach the UI. Any other server message still passes through verbatim so future real failures surface unchanged.