Bind VictoriaLogs on IPv6 so the mesh can ship journald to it

VictoriaLogs, like the VM scraper, is IPv4-only by default: ":9428" binds
0.0.0.0 only, so ns1/ns2 pushing journald over the IPv6 mesh got "connection
refused" while control's own loopback (v4) upload worked. Add -enableTCP6 so it
binds [::] (dual-stack), matching the flag already used for the scraper.

Also simplify the systemd-journal-upload override to just startLimitIntervalSec=0
(retry forever / self-heal) and drop the SuccessExitStatus masking: a persistent
sink failure should stay loud rather than be hidden behind a green deploy.

docs/src/monitoring.md

@@ -56,6 +56,14 @@ systemd's own `services.journald.upload` → the `/insert/journald` endpoint
 loopback so its logs survive a mesh outage, `ns1`/`ns2` push over the mesh, and
 9428 is firewall-scoped to the mesh like everything else.
 
+> Same IPv4-only default as the scraper: VictoriaLogs binds `0.0.0.0:9428` for a
+> bare `:9428`, so mesh (IPv6) pushes from ns1/ns2 are refused until you pass
+> `extraOptions = [ "-enableTCP6" ]` (binds `[::]`). Verify the bind on `control`:
+>
+> ```
+> ss -tlnp | grep 9428   # want [::]:9428, not 0.0.0.0:9428
+> ```
+
 Query logs from Grafana via the provisioned **VictoriaLogs** datasource (Explore
 view, LogsQL), or directly in the built-in UI at `http://[control]:9428/select/vmui`.
 Logs are tagged with `_HOSTNAME` and `_SYSTEMD_UNIT`, so to follow one service