ci(sfw): scope VP_INSECURE_TLS to the Linux matrix entry only

Only Linux actually needs the TLS-bypass against sfw v1.11.0:

- Linux (ubuntu-latest): runner doesn't preinstall Node 22.18 into
  vp's cache, so `sfw vp i -g pnpm@9.15.0` triggers vp's HttpClient
  to fetch nodejs.org/.../SHASUMS256.txt through sfw. rustls rejects
  sfw's broken CA (UnknownIssuer) — flag required.

- macOS / Windows: runners already have Node 22.18 in vp's cache.
  vp never traverses sfw with its HttpClient in this test; the only
  HTTPS through sfw is npm's (lenient Node TLS). No flag needed —
  and leaving verification enabled there confirms the bypass is
  scoped, not blanket.

Plumbed via a per-matrix-entry `vp_insecure_tls` value. The shared
HTTP client treats an empty `VP_INSECURE_TLS` env as unset (the
truthy-only parser added in the previous commit), so the empty
value on macOS/Windows is a no-op.

Author: fengmk2

.github/workflows/ci.yml

@@ -906,16 +906,25 @@ jobs:
             target: x86_64-unknown-linux-gnu
             sfw_asset: sfw-free-linux-x86_64
             vp_bin: vp
+            # Only Linux needs the TLS-bypass: the ubuntu-latest runner
+            # doesn't preinstall Node 22.18 into vp's cache, so vp's HttpClient
+            # (rustls) fetches `nodejs.org/.../SHASUMS256.txt` through sfw and
+            # hits the upstream EKU bug. macOS/Windows runners ship Node in
+            # vp's cache already, so vp never calls its HttpClient through sfw
+            # in this test — leave the verification on there.
+            vp_insecure_tls: '1'
           - os: namespace-profile-mac-default
             target: aarch64-apple-darwin
             sfw_asset: sfw-free-macos-arm64
             vp_bin: vp
+            vp_insecure_tls: ''
           - os: windows-latest
             target: x86_64-pc-windows-msvc
             sfw_asset: sfw-free-windows-x86_64.exe
             # On Windows vp ships as `vp.exe`; sfw spawns its child process
             # directly without applying PATHEXT, so the bare `vp` lookup fails.
             vp_bin: vp.exe
+            vp_insecure_tls: ''
     runs-on: ${{ matrix.os }}
     steps:
       - uses: taiki-e/checkout-action@7d1e50e93dc4fb3bba58f85018fadf77898aee8b # v1.4.2
@@ -982,18 +991,18 @@ jobs:
         run: sfw --version
 
       - name: Run `sfw vp install` against a real repo
-        # TODO(SocketDev/sfw-free#30, SocketDev/sfw-free#43): drop `VP_INSECURE_TLS`
-        # once sfw ships the EKU fix. Verified against sfw v1.11.0
-        # (releases/latest as of 2026-05-28) on Linux: vp's HTTPS request to
-        # nodejs.org through sfw still fails with
-        #   "invalid peer certificate: UnknownIssuer"
-        # because sfw's CA carries a present-but-empty Extended Key Usage
-        # extension that rustls rejects. macOS happened to pass only because
-        # the runner already has Node 22.18.0 cached, so vp didn't have to
-        # traverse sfw for SHASUMS — not a fix. Keep this flag on every
-        # matrix entry until upstream ships the EKU fix.
+        # TODO(SocketDev/sfw-free#30, SocketDev/sfw-free#43): drop `vp_insecure_tls`
+        # from the Linux matrix entry once sfw ships the EKU fix. Verified
+        # against sfw v1.11.0 (releases/latest as of 2026-05-28): on Linux,
+        # vp's HTTPS request to nodejs.org through sfw still fails with
+        # "invalid peer certificate: UnknownIssuer" because sfw's CA carries a
+        # present-but-empty Extended Key Usage extension that rustls rejects.
+        # macOS/Windows runners cache Node 22.18 in vp's directory, so vp
+        # doesn't call its HttpClient through sfw — leaving TLS verification
+        # enabled there gives us coverage that the bypass *isn't* used on
+        # those platforms.
         env:
-          VP_INSECURE_TLS: '1'
+          VP_INSECURE_TLS: ${{ matrix.vp_insecure_tls }}
         run: |
           set -euo pipefail
           # Force the registry-fetch path: install a pinned pnpm globally so