Add sidebar navigation and global command search

docs/guides/authentication.md

@@ -20,7 +20,7 @@ their access checks. HTTPS requirements still apply. See the
    password. Only the holder of the token can create the first administrator.
 4. Remove `EC_SETUP_TOKEN` after setup and restart/recreate the controller.
    Setup remains closed once any user exists, even if the token is still set.
-5. Use **Administration → Users** to create additional accounts. Share temporary
+5. Use **Admin → Users** to create additional accounts. Share temporary
    passwords privately; each user must change theirs on first login.
 
 Existing installations become protected on upgrade. Existing game servers and

docs/guides/collections.md

@@ -37,7 +37,7 @@ It fills deficits without changing existing servers' files.
    plan. Review the change summary and the map table grouped by game.
 4. Check the required key coverage for each game. Available keys count once
    across the full lineup, and every new server needs a key. If a game is short,
-   open **Administration → Keys** to add keys or wait for assigned keys to be
+   open **Admin → Keys** to add keys or wait for assigned keys to be
    released. Returning to the dialog rechecks the pools and fleet.
 5. Review the capacity summary. Expand its details for CPU, memory, ports, and
    startup slots. Capacity estimates are advisory: queued launches can wait for
@@ -142,7 +142,7 @@ All collections and individual launches share one startup queue, ordered by requ
 time. By default, one server starts at a time. Its startup slot remains occupied
 until the host agent confirms container health, game status and the selected map
 are verified, and RCON reports a current Plutonium revision.
-Only then can the next queued server start. Set **Concurrent server startups** in **Administration → Settings** to
+Only then can the next queued server start. Set **Concurrent server startups** in **Admin → Settings** to
 a positive integer to allow more simultaneous startups. Each worker pass admits
 at most the available slots, even if an attempt fails immediately.
 
@@ -190,7 +190,7 @@ against the remaining fleet.
 2. Choose a game and map. The dialog automatically checks the current promoted
    setup, latest game files, available lobby, and game key pool as selections change.
 3. Review the readiness summary and resolve any displayed blockers. When no game
-   key is available, open **Administration → Keys** and add one or wait for a key
+   key is available, open **Admin → Keys** and add one or wait for a key
    to be released. Returning to the launch dialog rechecks availability; **Retry checks**
    also runs the checks again.
 4. If needed, expand **Advanced settings** for runtime and network overrides.

docs/guides/getting-started.md

@@ -46,13 +46,13 @@ Proxy the HTTPS address to controller port 3000. Open the dashboard and follow
 `.env` and run `docker compose up -d` to recreate the controller. Setup stays
 closed once an account exists.
 
-Add other users under **Administration → Users**. The
+Add other users under **Admin → Users**. The
 [access guide](authentication.md) explains roles, proxy configuration, and
 password recovery.
 
 ## Prepare a game host
 
-1. Open **Library → Game Files** and upload the complete local folder for T5 or
+1. Open **Releases → Game files** and upload the complete local folder for T5 or
    T6, including DLC. Uploads can run before any host is enrolled. The latest
    verified upload becomes that game's default files.
 2. Open **Fleet → Hosts → Add Host**, configure the host's game-port range and
@@ -67,7 +67,7 @@ base game files; each instance has its own writable data. See
 
 ## Launch your first server
 
-1. Save Plutonium server keys in the T5 or T6 pool under **Administration → Keys**.
+1. Save Plutonium server keys in the T5 or T6 pool under **Admin → Keys**.
 2. Open **Create server** and choose a game and map. Readiness checks run
    automatically. For a reusable lineup, use **Fleet → Collections** instead.
 3. Resolve any launch blockers and choose **Launch server**. Provisioning queues

docs/guides/maintenance.md

@@ -1,6 +1,6 @@
 # Maintenance
 
-Open **Operations → Maintenance** to keep existing servers healthy and current.
+Open **Activity → Maintenance** to keep existing servers healthy and current.
 Maintenance owns observations, policies, schedules, requests, and verification of
 maintenance outcomes. Provisioning owns lifecycle execution, player checks,
 conflicts, rolling capacity, container recovery, and persistent operation history.
@@ -98,7 +98,7 @@ Schedules survive application restarts. Missed days, including while globally
 paused, become one run on resume. Pending work is deduplicated per server. The
 worker starts on the first application request, so keep the app running and
 reachable. Finished scheduled and legacy maintenance activity is retained for
-30 days by default (configurable in Administration → Settings); update attempt records remain durable.
+30 days by default (configurable in Admin → Settings); update attempt records remain durable.
 
 ## Health recovery and configuration drift
 

docs/guides/metrics.md

@@ -90,7 +90,7 @@ Observations are recorded by the existing status worker. Each remains valid unti
 
 Capacity comes from `sv_maxclients` / `sv_maxClients` in the status response. When unavailable, the UI displays unknown rather than assuming a four-player limit. Capacity coverage is the map time for which every tracked lobby reported both occupancy and capacity.
 
-Collection begins after this feature is installed; previous occupancy cannot be reconstructed. Samples default to 31 days of retention; Administration → Settings can change this period. Cleanup runs during collection and in the background. They survive removal of a server and contain no player identities. The additive database table is created automatically on startup.
+Collection begins after this feature is installed; previous occupancy cannot be reconstructed. Samples default to 31 days of retention; Admin → Settings can change this period. Cleanup runs during collection and in the background. They survive removal of a server and contain no player identities. The additive database table is created automatically on startup.
 
 ## API
 

docs/guides/native-hosts.md

@@ -555,7 +555,7 @@ on heartbeats, including vanished caches. The latest published version of each g
 is always retained. With agent 1.4.7 or newer, an older host copy is automatically
 eligible for removal once no live instance reservation on that host references it.
 The game-file minimum count, supersession grace period and explicit protections in
-Administration → Settings also apply. Stopped,
+Admin → Settings also apply. Stopped,
 provisioning, and rebuilding instances still pin their version. The agent also
 refuses deletion if any Docker container (including stopped containers) mounts
 those files. Cleanup includes partial downloads and retries after interruption.

docs/guides/provisioning.md

@@ -1,6 +1,6 @@
 # Provisioning
 
-Open **Operations → Provisioning** for instance lifecycle work and persistent
+Open **Activity → Operations** for instance lifecycle work and persistent
 activity. **Fleet → Collections** owns reusable lineups and collection launch
 progress; their individual operations remain visible in Provisioning.
 Provisioning owns the queues, safety checks, execution, and
@@ -83,7 +83,7 @@ same key. Confirmed removal releases it for another launch. Failed or ambiguous
 creation keeps the assignment while cleanup may still be required.
 
 An unstarted creation cancelled before dispatch releases its key immediately.
-Administrators can add and remove available keys in **Administration → Keys**;
+Administrators can add and remove available keys in **Admin → Keys**;
 assigned keys cannot be removed. Existing keys are migrated into their game
 pool, retaining assignments for existing servers and pending work. If a legacy
 rebuild has an uncertain result and used a different key, both possible keys
@@ -248,7 +248,7 @@ See [native host management](native-hosts.md) for command delivery and recovery.
 
 ## Concurrency limits
 
-Administration → Settings separates Concurrency and Retention, with independent
+Admin → Settings separates Concurrency and Retention, with independent
 save actions. Existing fleet restart, startup and destruction limits continue to
 apply. Additional per-host restart, startup and destruction limits, a combined
 lifecycle limit, a rebuild limit, and a limit on hosts preparing game files default

docs/guides/settings.md

@@ -1,6 +1,6 @@
 # Fleet settings
 
-Administration → Settings has independent **Concurrency** and **Retention**
+Admin → Settings has independent **Concurrency** and **Retention**
 sections. Settings persist in SQLite, apply without restarting the controller,
 and are writable only by administrators. Saving one section preserves the other
 section's saved values. Upgrades preserve existing values and add new defaults.