grafana dashboards: shorten panel descriptions

Cut every panel/board description down to a short statement of what the
number is. Drops the design-reasoning prose, edge-case notes, and
operator-attributed quotes that had accumulated in an earlier pass —
useful context while building the boards, wrong shape for a tooltip an
operator glances at mid-incident.

nix/host-modules/swarm-grafana/dashboards/logstore.json

@@ -1,7 +1,7 @@
 {
   "title": "hyperhive · logs (victorialogs)",
   "uid": "hyperhive-swarm-logstore",
-  "description": "The swarm's log pipeline: whether the store is healthy (top) and which sources are actually feeding it (bottom). One of the per-service boards split out of the combined swarm-services page. The two halves answer different questions and are on one board on purpose — aggregate ingestion stays normal on host-tier units while a whole tier ships nothing, so a healthy top half is not evidence about the bottom one.",
+  "description": "The swarm's log pipeline: store health and log sources.",
   "editable": true,
   "refresh": "1m",
   "schemaVersion": 39,
@@ -17,7 +17,7 @@
       "id": 1,
       "type": "timeseries",
       "title": "Log rows ingested (range)",
-      "description": "Rows accepted by the log store over the range. ⚠️ This counts what ARRIVED, never what became findable — the pipeline shipped for days with every record carrying a placeholder in place of its message, while this counter climbed normally. A healthy line here is necessary and not sufficient; the check that closes it is a query returning readable lines.",
+      "description": "Log rows accepted by the store in the selected range.",
       "datasource": {
         "type": "prometheus",
         "uid": "@datasourceUid@"
@@ -74,7 +74,7 @@
       "id": 2,
       "type": "timeseries",
       "title": "Log store size on disk",
-      "description": "Compressed on-disk size, split by the store's own `type` label (storage vs indexdb). Retention is 30 days, so this is expected to climb to a plateau rather than forever; a straight line past that is the signal.",
+      "description": "Compressed on-disk size of the log store.",
       "datasource": {
         "type": "prometheus",
         "uid": "@datasourceUid@"
@@ -131,7 +131,7 @@
       "id": 3,
       "type": "stat",
       "title": "Log store free disk",
-      "description": "Free space on the volume holding the log store. It shares a filesystem with the metrics store, so the two panels move together — a drop here that the metrics one does not show means something outside this swarm is filling the disk.",
+      "description": "Free disk space on the log store's volume.",
       "datasource": {
         "type": "prometheus",
         "uid": "@datasourceUid@"
@@ -194,7 +194,7 @@
       "id": 4,
       "type": "stat",
       "title": "Log store errors",
-      "description": "Internal errors plus rejected HTTP requests. Healthy value is zero. ⚠️ A wrong OTLP path answers 400 and lands here, and so does a right path with a bad payload — the status code alone does not separate them, only the store's own log does.",
+      "description": "Internal errors and rejected requests.",
       "datasource": {
         "type": "prometheus",
         "uid": "@datasourceUid@"
@@ -268,7 +268,7 @@
       "id": 5,
       "type": "stat",
       "title": "Rows in range · all sources (control)",
-      "description": "Deliberately ungrouped, and it is what makes the two tables below readable. An empty table renders identically whether the query is malformed or the source genuinely never shipped: nonzero here with an empty table means the QUERY is broken; zero here means the store really is empty for this range. Read it against `Log rows ingested` above too — that counter is the same quantity measured from the store's own metrics rather than by querying, so the two disagreeing means rows arrived that a query cannot reach.",
+      "description": "Total log rows in the selected range, all sources.",
       "datasource": {
         "type": "victoriametrics-logs-datasource",
         "uid": "@logsDatasourceUid@"
@@ -330,7 +330,7 @@
       "id": 6,
       "type": "bargauge",
       "title": "Rows by unit",
-      "description": "Every `_SYSTEMD_UNIT` present in the range, discovered rather than enumerated — nothing here names a unit, so a source that starts shipping appears on its own. ⚠️ Absence means NOT COLLECTED, which is not the same as not running: the collector's journald receiver only reads the units listed in `services.hyperhive.swarm.otel.journaldUnits`, so a unit missing from that list can be running and logging and still never reach this board.",
+      "description": "Log rows, split by systemd unit.",
       "datasource": {
         "type": "victoriametrics-logs-datasource",
         "uid": "@logsDatasourceUid@"
@@ -382,7 +382,7 @@
       "id": 7,
       "type": "bargauge",
       "title": "Rows by host",
-      "description": "The same count grouped by `_HOSTNAME`. Read together with the unit table this separates two very different failures: one host contributing nothing is a collector or journal-linkage problem on that host, while a unit missing across every host is a configuration problem in what gets collected.",
+      "description": "Log rows, split by host.",
       "datasource": {
         "type": "victoriametrics-logs-datasource",
         "uid": "@logsDatasourceUid@"
@@ -434,7 +434,7 @@
       "id": 8,
       "type": "timeseries",
       "title": "Rows over time, by unit",
-      "description": "The tables say who shipped over the whole range; this says when. A line that stops is a source that died, and it is the only view here that distinguishes that from one which never existed — a source absent for the entire range looks the same as an unknown one in a table, but shows up here as a line that ends.",
+      "description": "Log rows over time, split by unit.",
       "datasource": {
         "type": "victoriametrics-logs-datasource",
         "uid": "@logsDatasourceUid@"