Cardano Updates

Replace the generic FindDIDSigningKeys with six explicit, purpose-specific classes:
- FindIssuerSigningKeys: for credential issuance (assertionMethod)
- FindAuthenticationSigningKeys: for proving DID ownership (authentication)
- FindKeyAgreementSigningKeys: for encryption/key agreement (keyAgreement)
- FindCapabilityInvocationSigningKeys: for invoking delegated capabilities
- FindCapabilityDelegationSigningKeys: for delegating capabilities to others
- FindRevocationSigningKeys: for revoking credentials/keys

This improves code clarity and scalability by making the purpose of each key
type explicit at the API level. Each search function includes comprehensive
W3C DID Core Specification references and documentation.

All explicit finders are thin wrappers delegating to the refactored
FindSigningKeys implementation that now supports all six DID verification
relationships via PURPOSE_TO_VERIFICATION_RELATIONSHIP mapping.

Fixes #596

Signed-off-by: Anshika Chaubey <[email protected]>

NumericDate claims per RFC 7519 must be emitted in seconds, not milliseconds.
Several SDK code paths were using Date.now() directly, which returns milliseconds,
causing tokens to be emitted with iat/exp values interpreted as far-future dates
when conforming verifiers parse them as seconds. This breaks interoperability with
RFC 7519-compliant consumers.

Fixed affected sites:
- HandleRequestCredential.ts: createJWT() and createSDJWT() methods
- CreateCredentialRequest.ts: OID4VCI proof JWT

All NumericDate claims now use Math.floor(Date.now() / 1000) to emit seconds.

Tests added to verify iat/exp are in seconds (NumericDate range):
- HandleRequestCredential.test.ts: RFC 7519 NumericDate Compliance tests
- CreateCredentialRequest.test.ts: OIDC proof JWT iat seconds validation

Fixes #610

Signed-off-by: Anshika Chaubey <[email protected]>

Switch `ChainData` and `Attributes` to use `ByteArray`

In order to avoid pinned memory fragmentation it is beneficial to use
`ByteArray` instead of `ByteString`

Implement `EncCBORGroup` instance for `DijkstraBlockBody`

GHC 9.14.1's `armv7a-android` cross GHC ships *both*
`<prefix>deriveConstants` and an unprefixed `deriveConstants` in
its `bin/` (the latter for build-host use).  `ghcShim`'s
single-pass loop iterated `${ghc}/bin/*` alphabetically, hit
`armv7a-...-deriveConstants` first, and the case branch
synthesised an unprefixed-fallback alias
`$out/bin/deriveConstants -> <prefix>deriveConstants` (the
`[ -e ]` guard was for that fallback, not the raw link).  When
the loop later reached the real `deriveConstants`, the raw
`ln -s "$f" "$out/bin/$base"` crashed with "File exists".

Earlier cross GHCs only shipped `<prefix>deriveConstants`, so
the fallback was the sole producer of `$out/bin/deriveConstants`
and never collided.  GHC 9.14.1 added the unprefixed sibling and
exposed the race.

Switch to a two-pass shape: pass 1 links every source bin/ entry
under its own name, pass 2 synthesises unprefixed aliases only
for prefixed names that have no real unprefixed sibling.  Real
files always win; aliases only fill genuine gaps.

Same fix in both `builder/build-cabal-slice.nix` and
`builder/shell-for-v2.nix` (which carries an identical shim for
the dev shell's cross-cabal wrapper).