Build weak-RSA test fixtures without jwk.Import

[jhrozek]

Unblocks the jwx renovate PRs — #225 (v3.2.0) and #226 (v4) — which both fail on
the same four tests, for a reason that has nothing to do with the package:

jwk.Import: key validation failed: jwk.RSAPublicKey: rsa modulus too small:
got 1024 bits, need at least 2048

jwx 3.2.0 added an RSA modulus floor to Validate() and began calling
Validate() from Parse/ParseKey as well as Import. 3.0.13 has neither. So
the shared helper mintRSABits(t, kid, 1024) can no longer construct the weak
fixture, and TestWeakRSAKeyRejected, TestWeakRSAKeyFromProviderRejected,
TestKeyUnsupportedVsUnknownKID and TestKeyUnsupportedDetailIsLogSafe all die
at setup without ever reaching their assertions. Test scaffolding only — no
production behaviour is broken.

Test-only change: one file, authn/validate_test.go.

The floor still earns its place, but only on one path

A KeyProvider hands over raw crypto keys that never go through jwk, so our
check is the only one there. On the JWKS path jwx now rejects a short key during
Parse, before our filter runs. So rather than delete the coverage, it moves to
where it is still reachable:

• mintRawRSA builds the key and signs a token without touching jwk, for the
  two tests that genuinely need a weak key.
• TestWeakRSAKeyFromProviderRejected uses it, and is tightened while here: it
  asserted only that the reason was not ReasonSignature, where it can now
  assert ReasonKeyUnsupported and the cause text.
• TestKeyUnsupportedDetailIsLogSafe moves to the provider path, which keeps its
  "the modulus must never appear" assertion meaningful — a weak RSA key is the
  thing that could leak one.
• TestKeyUnsupportedVsUnknownKID switches its unusable key to use: enc,
  equally permanent and survives jwx validation. That test's subject is the
  unusable-vs-absent distinction, not the floor specifically.
• TestWeakRSAKeyRejected is deleted rather than rewritten: no public jwx API
  can build the fixture under 3.2, and the other ineligibility causes on that
  path are already covered by TestKeyUsageFilter and TestKeyOpsFilter. A
  comment records why the gap is deliberate, so it does not get "fixed" later.

keyTypeMatchesAlg keeps its floor as defence-in-depth for consumers on older
jwx — it is unreachable under 3.2, not wrong.

One thing to decide before #225 merges — not fixed here

Key-set parsing is strict by default, so under 3.2.0 a JWKS containing one
sub-2048-bit RSA key fails to parse entirely: Lookup fails and every token gets
503 keys_unavailable, including ones signed by perfectly good keys in the same
set. On 3.0.13 that weak key parses and we filter it out as a single ineligible
candidate, and the good keys keep working.

That is a production behaviour change arriving with a dependency bump rather than
with anyone's code, so it deserves to be a decision. jwk.WithStrictKeySetParsing(false)
would degrade it back to "one unusable key", which matches this package's own
per-key filtering — and the resulting UnsupportedKey placeholder would be
filtered by keyEligible anyway. The catch is that it is typed
GlobalParseOption and applied via jwk.Configure, so if it cannot be threaded
per-parse into the cache, a library probably should not be setting it
process-wide. There is also jwk.WithMinRSAModulusBits if the floor itself ever
needs tuning.

Deliberately left out of this PR so the CI unblock is not entangled with a
policy call.

Test plan

Verified green both ways, since passing on only one is the whole problem:

• go test -race ./authn/ on 3.0.13 as pinned on main.
• go test -race ./authn/ on 3.2.0, applied in a scratch copy — the combination
  Update module github.com/lestrrat-go/jwx/v3 to v3.2.0 #225 and Update module github.com/lestrrat-go/jwx/v3 to v4 #226 currently fail on.

The rest of the suite is unchanged by this PR and left to CI.