docs(networking): facts + structure pass on gateway, network, jobq, observability, matrix

gateway.md: split the opener into what/audience/enable; vhost map in two
tables (swarm-service vhosts declared by their own modules, then the hive
vhost) matching vhosts.nix and the service modules; gateway.enable exists
and is set with mkDefault by the modules that need it; Basic auth scope,
dashboard /health/ prefix, error-page rendering, matrix body limit and
forge link source corrected; nginx internals grouped under one Internals
section with their headings unchanged.

network.md: gateway and dnsmasq run on the host, not in a container;
network.enable is set by the modules that need it; shared-netns firewall
rule covers every swarm service container; hive-priv writes the nspawn
conf; domain sentence rewritten; removed options moved into <details>.

jobq.md: swarm-controller runs its own graph; swarm UI /jobs and BU1LDS
show different graphs drawn by the same component.

observability.md: swarm tier first; history narration cut; network access
deduplicated into a link to network.md; options link made absolute.

matrix.md: swarm.matrix vs deploy.matrix namespaces; tuning, firewall and
SSO options under deploy.matrix; .well-known is served on the hive domain;
roadmap sentence deleted; stale hive-c0re provisioning claims fixed;
serverName upgrade note moved into <details>.

Refs #3902

docs/scheduler/jobq.md

@@ -1,11 +1,13 @@
 # The job queue, for operators
 
-Every container operation — rebuild, first-spawn, a config-PR deploy,
-power changes — runs through one shared job queue. This page explains
-what the job queue _is_, as a general idea, independent of what any one
-subsystem uses it for. For the hive-c0re-specific step catalogue and the
-engineering internals (scheduler, leases, resource windows) see
-[`coordinator.md`](coordinator.md) instead.
+Long-running work runs through a job graph. The swarm controller keeps one
+for swarm-level work — creating an agent's identity, forge user and config
+repo. Each hive's hive-c0re keeps its own for container operations —
+rebuild, first-spawn, a config-PR deploy, power changes. This page explains
+what the job queue _is_, as a general idea, independent of what either uses
+it for. For the hive-c0re step catalogue and the engineering internals
+(scheduler, leases, resource windows) see [`coordinator.md`](coordinator.md)
+instead.
 
 ## What the job queue is, in the abstract
 
@@ -24,18 +26,18 @@ Two ideas are all there is to it:
 
 The engine's whole job is: whenever a step's ordering and resource needs
 are both satisfied, run it. It has no opinion on what the steps _do_ —
-that's supplied by whoever builds the graph. hive-c0re is the one thing
-building graphs on it today, but nothing about the engine is specific to
-containers or rebuilds; there's nothing stopping another subsystem from
-using the same engine for its own unrelated queue.
+that's supplied by whoever builds the graph. The swarm controller and
+hive-c0re each build their own graph on it, and nothing about the engine
+is specific to either.
 
 ## Watching it happen
 
-Each **row** you see in a queue view (the **BU1LDS** page's R3BU1LD QU3U3
-— see [`web-ui/dashboard.md`](../web-ui/dashboard.md) — and swarm-ui's
-`/jobs` page both render the same underlying graph) is one job; the rows
-nested under it are that job's steps, in order (occasionally a couple run
-side by side). A step shows one of:
+Two views, one per graph, drawn by the same component: the swarm UI's
+`/jobs` page shows the swarm controller's graph, and the hive dashboard's
+**BU1LDS** page (R3BU1LD QU3U3 — see
+[`web-ui/dashboard.md`](../web-ui/dashboard.md)) shows that hive's. Each
+**row** is one job; the rows nested under it are that job's steps, in
+order (occasionally a couple run side by side). A step shows one of:
 
 <!-- vale write-good.Passive = NO -->