WICKET-7190 Encrypt URLs deterministically so they stay cacheable

Authenticated encryption draws a random nonce, so re-encrypting the same URL
produced different ciphertext every time. CryptoMapper worked around that with a
per-RequestCycle plaintext -> ciphertext memo: enough to keep URL normalisation
from redirecting endlessly, but it died with the request. Every page view
therefore handed the browser brand-new URLs for every JavaScript, CSS and image
resource. Those responses carry a one-year cache duration, and because the URL
itself changed the browser could not even issue a conditional request, so each
page view re-downloaded every resource; through CSS, whose body embeds resource
URLs, the effect compounded. Wicket 10 did not have this problem, as SunJceCrypt
derived its IV from a per-session salt and was thereby deterministic.

Add an explicit deterministic encryption path to the crypt API and use it for
URLs:

- ICrypt.encryptDeterministic and ICryptScheme.encryptDeterministic. Required
  rather than an opt-in with a random-nonce fallback, so that a scheme cannot
  silently reintroduce the redirect hazard. Both write the existing ciphertext
  format, so decryption is unchanged.
- AbstractAesGcmCryptScheme derives the nonce as
  HMAC(HMAC(key, "wicket-deterministic-nonce"), len(aad) || aad || plaintext)
  truncated to 96 bits, covering AES-256-GCM and AES-256-GCM-SIV alike.
- CryptoMapper encrypts with the deterministic path, which lets the entire memo
  go: ENCRYPTED_URL_CACHE, encryptString, rememberEncryption and
  getEncryptionMemo, along with the verification decrypt they required.

Determinism reveals that two ciphertexts encrypt equal plaintexts, and lets a
key holder confirm a guessed URL. With the default per-session key that stays
confined to a single session, and it is what Wicket 10 already did. The page
store, the "remember me" cookie and the upload token keep randomized nonces.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>