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.

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.