fix(chrome): ship NSS's runtime providers and gate on a real render

What was broken

google.com/chrome@155.0.8059.84 installs, and --version works, but the browser aborts as soon as it starts:

FATAL:crypto/nss_util.cc:146] nss_error=-8023

Chrome loads libnss3 from its own lib/ (RPATH $ORIGIN/..). NSS then opens its providers from that directory with dlopen, outside the DT_NEEDED graph. The recipe copied libsoftokn3.so and libfreebl3.so, but not libfreeblpriv3.so, which does softokn's actual crypto (libfreebl3 is only its stub).

Two checks hid it:

• --version (the recipe test and the release gate's only check) never loads NSS.
• The recipe health check exports every dependency's lib/ on LD_LIBRARY_PATH, so NSS finds the missing library there.

The change

• Recipe: copies every provider NSS opens at runtime (NSS_RUNTIME_PROVIDERS): libsoftokn3, libfreebl3, libfreeblpriv3 with their .chk signatures, and libnssckbi for the built-in roots.
• Release gate (.github/scripts/linux-native-browser.ts): after --version, it renders a page with the installed package as the unprivileged CI user, using --headless=new --dump-dom. The environment holds only HOME and a PATH without the package, so no LD_LIBRARY_PATH can help.
  • The sandbox stays on. On kernels that restrict unprivileged user namespaces (Ubuntu 23.10+), the gate loads an AppArmor profile granting userns to that one binary, the same shape as Ubuntu's own /etc/apparmor.d/chrome, and removes it afterwards.
• Unit test (test/chrome-nss-runtime.test.ts): pins the provider list and the gate's clean render. It fails against the current recipe.

Proof

Ubuntu 24.04, rendering as an unprivileged user, sandbox on, clean environment:

Integration

The gate tests the published artifact, so it stays red until google.com/chrome is rebuilt from this recipe and published as a new artifact (the accepted 155.0.8059.84 artifact is left as it is). That rebuild belongs to the normal release lane. This PR only changes source and the gate, and I'm not merging it myself.