ci(crypto): make the FIPS gate report its own failure

What

TestFIPSGateEnvironment asserts the environment test:crypto-fips declares — the module enabled, and its version equal to the pin — armed by a new ARTIFACT_REGISTRY_FIPS_EXPECT_VERSION variable, plus a test -n script line so dropping the variable fails the job too.

Why

The gate is green with FIPS off. Proved by running the job's own script with its FIPS variables removed: TestAssertFIPS_Enabled skips the branch it cannot reach, TestAssertFIPS_Disabled passes, TestFIPSVersion passes, package ok. So the job could stop proving what it exists to prove and nothing would say so.

The two variables also fail independently, which is why one assertion is not enough:

Dropped	Effect
GODEBUG=fips140=only	The module can still be active through GOFIPS140, so a version check alone misses it
GOFIPS140=v1.0.0	The module stays active but reports latest, silently losing the certified pin

Falsifiability, all four run by hand:

Environment	Result
The job's own (both variables plus the expectation)	PASS
GOFIPS140 dropped	FAIL — latest ≠ v1.0.0
No FIPS at all	FAIL on Enabled()
Unarmed	SKIP, default suite green

The expectation must equal GOFIPS140, so bumping the pinned module version means bumping both in the same edit. That is deliberate — a certified-module change is compliance-relevant and should require a visible edit. Renovate does not manage GOFIPS140, so no bot trips it.

Scope

This is the self-reporting half of the finding only. The other half — that the gate does not cover the whole binary — is an S04-A acceptance criterion rather than an oversight, breaks today under fips140=only in five packages that make non-security MD5/SHA-1 calls, and is downstream of the FIPS-mode variant not yet existing. That is recorded on the issue rather than here.

The two existing branch tests are unchanged: they are unit tests of AssertFIPS, not gates. TestFIPSVersion's comment now defers the pin claim to the new test rather than describing behaviour it does not assert.