docs(mesh): note admin-only management, dev-mode diagnostics, and the subnet env var (#1288)

- Note that managing the mesh (the per-node toggle and stack opt-in or
  opt-out) requires an administrator and that non-admin users see the
  Routing tab read-only, matching the access model the tab enforces.
- Document the [Mesh:diag] developer-mode logs in the Diagnostics section
  so operators can trace routing decisions and operation timing.
- Add SENCHO_MESH_SUBNET to .env.example; it was documented on the feature
  page but missing from the env template.

.env.example

@@ -127,6 +127,13 @@ SENCHO_EXPERIMENTAL=false
 # the next mesh dial re-opens it. Default 0 (persistent).
 SENCHO_MESH_PROXY_TUNNEL_IDLE_MS=0
 
+# Mesh network subnet for this node. Leave unset to let Sencho pick the first
+# free /24 from its candidate list (172.30.0.0/24, 172.31.0.0/24, 10.42.0.0/24,
+# 10.43.0.0/24), or adopt the existing sencho_mesh network's subnet when it is
+# already present. Set a specific CIDR only when you need to avoid an overlap
+# with another network on this host. Configured independently per node.
+# SENCHO_MESH_SUBNET=10.42.0.0/24
+
 # Maximum bytes a single Git Source clone may download from the Git host before
 # it is aborted. This bounds network transfer and abuse, not the decompressed
 # on-disk size. A shallow clone of a compose repo is tiny; raise this only if

docs/features/sencho-mesh.mdx

@@ -42,7 +42,7 @@ App-layer authentication is **not** in scope. Postgres still needs a password, R
 
 ## Enable the mesh
 
-Mesh lives under **Fleet → Routing**.
+Mesh lives under **Fleet → Routing**. Managing it (the per-node mesh toggle and stack opt-in or opt-out) requires an administrator; non-admin users see the Routing tab as read-only.
 
 <Frame caption="Fleet → Routing, Table view. Each node card shows mesh stack count, published aliases, per-alias Test probe, and an Add stack to mesh action.">
   <img src="/images/sencho-mesh/routing-tab-overview.png" alt="Sencho Mesh Routing tab Table view with node cards" />
@@ -89,6 +89,8 @@ The sheet shows:
 
 Mesh runs in-process on each node; there is no separate mesh container to inspect with `docker ps`.
 
+Enable **Developer Mode** under **Settings → Developer** to surface `[Mesh:diag]` lines in the container logs covering the forwarder's routing decisions (same-node versus cross-node, and which node-identity resolution won) and the timing of opt-in, opt-out, and alias-refresh operations (`docker logs sencho 2>&1 | grep '\[Mesh:diag\]'`). They are off by default and meant for one-off debugging; turn developer mode back off when you are done to keep log volume manageable.
+
 ## Mesh activity log
 
 The Routing-tab masthead has a **Mesh activity** button that opens a fleet-wide event log.