Port Dart's typed atKeys key material to at_java, with Dart-interoperable JSON #425

Is your feature request related to a problem? Please describe.

at_java's AtKeys models a keyfile as seven flat base64 Strings. Dart's at_auth
#2047 replaced that with a versioned keys[] document of self-describing key
material — keyId, keyPartType, keyAlgorithmType, bytes, operations,
createdAt, status. at_java cannot represent it, and the two SDKs' keyfiles are
currently mutually unreadable: at_java writes "version" as a JSON string where
Dart's parser requires an int, and Dart's "keys" array cannot bind into at_java's
Map<String,String>.

Describe the solution you'd like

Port the Dart implementation as follows...

Implement version specific JSON encode/decode such that atKeys JSON written by current and previous version of Dart can be loaded.

The legacy fields in AtKeys will be removed. Deprecated getters will be added to fix the current code and then ultimately be removed once CryptoProvider is ported.

Describe alternatives you've considered

Port like-for-like.

Additional context

Open questions for the team

1. CryptographicMaterial or KeyingMaterial? The latter is the actual term of
   art — NIST SP 800-57 defines "keying material", RFC 5869 uses "input keying
   material" (IKM). "Cryptographic material" is common informally (AWS KMS, Vault)
   but isn't a standards term. This is the type everything else nests inside, so
   worth settling before code.

2. Status or State? NIST SP 800-57 §7 defines a key state machine
   (pre-activation, active, suspended, deactivated, compromised, destroyed) and
   active is literally a NIST state. Against: our retired/dead are not NIST's
   deactivated/destroyed, and the wire field is status — so State would claim
   an alignment the values don't honour.

3. Do we need to support Dart's AtKeys.metadata passthrough? Dart parks every
   unrecognised top-level keyfile key there and writes it back flat. at_java has
   never modelled it, so the default is not to add it — but then at_java drops
   those keys on save.

4. What is the known vocabulary for operations? Dart has no known-values class
   for it, and the only values anywhere in its tree are sign and decrypt, both in
   tests — so Operation's known set has to be agreed rather than ported. Seed it
   from JWK key_ops (sign/verify/encrypt/decrypt/wrapKey/unwrapKey/
   deriveKey/deriveBits), or from just those two and let it grow?