fix(conformance): chainsaw checks use contains(), not unsupported =~

Every chainsaw `check` used the regex operator `=~` (`($stdout =~ 'X'): true`),
which chainsaw's expression engine rejects ('SyntaxError: Unknown char: ~') — so
EVERY such test failed on the assertion even when the behavior passed. Proven with
data-survival (R-STATE-01): the Longhorn canary genuinely SURVIVED pod destruction
(DATA_SURVIVED_OK) but the test FAILED on the `=~` syntax. Converted all 10 tests to
JMESPath `contains($stdout, 'X')` (data-survival's alternation → contains||contains).
data-survival now PASSES; the other 9 (later-phase components) are syntactically fixed
for when their phases deploy.

Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>

conformance/tests/l3-fault-injection/vpn-killswitch/chainsaw-test.yaml

@@ -51,14 +51,14 @@ spec:
                 echo "LEAK: vpn workload reached internet with tunnel down" >&2; exit 1
               fi
               echo NO_LEAK_OK
-            check: { ($stdout =~ 'NO_LEAK_OK'): true }
+            check: { (contains($stdout, 'NO_LEAK_OK')): true }
         - script:
             # AND: internet-class workload is unaffected.
             content: |
               set -euo pipefail
               kubectl -n "$NAMESPACE" exec egress-internet -- \
                 curl -fsS --max-time 5 https://api.ipify.org && echo INTERNET_UNAFFECTED_OK
-            check: { ($stdout =~ 'INTERNET_UNAFFECTED_OK'): true }
+            check: { (contains($stdout, 'INTERNET_UNAFFECTED_OK')): true }
     - name: when-tunnel-recovers-connectivity-returns
       try:
         - script: