fix(web-app-seaweedfs): stop variant 0 from overriding its own tor gate

`meta/services.yml` switches five services off on a tor node, all on the same
`'svc-net-tor' not in group_names`: frontend, sso, logout, dashboard and
prometheus. Its header says why, that the role is an object-storage backend and
"never a Tor-browser surface, so it rides no node onion".

Variant 0 overrode four of them with a literal `true` and left `frontend` out.
The overlay wins, so on a tor node the role contradicted itself: the vhost off,
the consumer surfaces on. Two independent failures in run 36745666606 follow
from that one split.

`/metricz` is asserted to carry `app="web-app-seaweedfs"`, a label that cannot
exist while no filer or master vhost is written, and the spec polls for it until
`--max-failures` aborts the job. The dashboard card is still emitted and its URL
is never onionised, because `utils/cache/domains.py` skips onion injection for a
role without a `services.tor` block and this role deliberately has none, so the
card points at `https://filer.seaweedfs.s3.<domain>` amid siblings on
`http://<app>.<node>.onion`; through the SOCKS proxy that host is unreachable,
the tab never opens and `waitForEvent("page")` times out.

The run supplies its own negative control: job 110003713181 is the same variant
0 without `svc-net-tor` in its inventory include, and there `frontend.enabled`
renders true, the metricz spec passes and no seaweedfs tile fails. The tor axis
is the only difference between it and the two failing jobs.

The overrides now carry the gate instead of overruling it. Deleting them was the
other option and is worse: they would fall back to the role's expression, which
also requires the provider in `group_names`, so the variant could stop
exercising the card on clearnet, which is what it exists for.

That the expression resolves is read from the code, not assumed:
`utils/cache/applications.py:294` deep-merges the variant as a raw string and
`:447` renders the merged result through `_render_with_templar`, the same single
pass that renders the identical expression in `meta/services.yml`.

7a70d27b7c is why this survived. Its lint demands that a variant switching SSO
on also pins the onion, it fired here, and the answer was the
`# nocheck: sso-variant-tor` this file still carries. The reason given is sound
and the marker stays: SSO cannot run over an onion this role does not serve.
What it excused was the missing tor pin, not a literal `true` overruling the
gate. No rule checks that today.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

roles/web-app-seaweedfs/meta/variants.yml

@@ -6,17 +6,17 @@
     container_backup:
       enabled: true
     sso:
-      enabled: true
-      shared: true
+      enabled: "{{ 'svc-net-tor' not in group_names }}"
+      shared: "{{ 'svc-net-tor' not in group_names }}"
     logout:
-      enabled: true
-      shared: true
+      enabled: "{{ 'svc-net-tor' not in group_names }}"
+      shared: "{{ 'svc-net-tor' not in group_names }}"
     dashboard:
-      enabled: true
-      shared: true
+      enabled: "{{ 'svc-net-tor' not in group_names }}"
+      shared: "{{ 'svc-net-tor' not in group_names }}"
     prometheus:
-      enabled: true
-      shared: true
+      enabled: "{{ 'svc-net-tor' not in group_names }}"
+      shared: "{{ 'svc-net-tor' not in group_names }}"
 - services:
     container_backup:
       enabled: false