Fix native Ed448 detection without crypto fallback

[neilberkman]

Summary

• Detect OTP's native Ed448 implementation without depending on the optional pure Erlang fallback.
• Validate Curve25519 and Curve448 adapters against fallback-independent RFC 8032 vectors.
• Report Ed25519, Ed25519ph, Ed448, and Ed448ph only after their actual sign and verify operations succeed.
• Make capability caching generation-safe across configuration changes, server restarts, FIPS transitions, and hot code loading.
• Document the native crypto adapters for both Curve25519 and Curve448.

Details

The Curve448 startup probe previously asked jose_jwa_curve448 to cross-verify a native signature. With crypto_fallback: false, that verifier has no SHAKE256 backend, so JOSE rejected a working jose_curve448_crypto adapter.

The startup probes now validate candidate adapters directly against RFC 8032 blank and non-empty known-answer vectors for Ed25519 and Ed448. Operational capability checks run outside jose_server, while short server-issued snapshots and conditional cache writes prevent partial or stale results without allowing a slow custom adapter to block configuration calls.

Cache generations use references to prevent ABA reuse across server restarts. Applied fallback state, native FIPS state, selected adapter code, and JOSE's transitive fallback modules participate in invalidation. Rolling code upgrades lazily migrate older cache tables.

Verification

• OTP 27 full ExUnit suite: 23 tests, 0 failures.
• OTP 28 full ExUnit suite: 23 tests, 0 failures.
• OTP 29 production compilation, native Ed25519/Ed448 smoke tests, and concurrent capability stress.
• Both rolling module-load orders exercised against the 1.11.12 beams.
• Elixir formatting and diff checks.
• Two independent adversarial code reviews; all actionable P2/P3 findings incorporated.

Fixes #198