Add the delegation credential (VDC) to the catalog

[stormer78]

Summary

DTGCredentialType carries six live subtypes — Membership, Relationship,
Invitation, Persona, Endorsement, Witness — and correctly deprecates RCard
per Working Draft 01. It has no Delegation.

DTG Credentials defines the VDC as a DTG edge credential, so nothing
downstream can be conformant until the catalog carries it.

Detail

Required shape per the specification:

• type MUST include "DelegationCredential"
• issuer: the delegator — an R-DID or M-DID for a person, device or agent; a
  C-DID where a community delegates to a VTA or other service; a P-DID where
  the delegation is made under a persona
• validUntil: REQUIRED, unlike the base structure — "an appointment with
  no expiry cannot be reasoned about by a verifier that cannot reach the
  delegator"
• credentialStatus: REQUIRED — revocation is how a delegator withdraws an
  appointment already made, so it must be checkable without contacting them
• credentialSubject.id: the delegate
• credentialSubject.delegation.scope: array, MUST contain at least one entry.
  "A VDC MUST NOT express an unbounded appointment by omitting or emptying
  scope."

Two of those are unusual enough to be worth encoding in the constructor rather
than left to callers: validUntil and credentialStatus are optional on every
other type and mandatory here, and an empty scope is a specification
violation rather than a permissive default. A new_vdc that takes them as
non-optional parameters, and rejects an empty scope, makes the invariant
unforgeable by construction.

Why it matters beyond adding a variant

The specification is explicit that the VDC differs in kind, not only in
payload: the other types attest that something is true about the graph, while
a VDC establishes representation. Verifying one requires scope containment,
chain resolution, invocation binding and timely revocation — none of which the
other types need.

That is worth flagging here because a catalog variant is necessary but nowhere
near sufficient: a consumer that treats a DelegationCredential like any other
DTG credential will accept a party as standing in for another without having
bounded what it may then do. The catalog should make the credential
constructible; it cannot make it safely verifiable on its own.

Sequencing

The VDC arrived in the specification recently (d7130a6), and
trustoverip/dtgwg-cred-spec#19 is the open draft adding it. Worth landing the
catalog variant behind that settling rather than ahead of it.

Smaller, unrelated

DTGCredentialType derives no PartialEq, so consumers assert by pattern
(matches!) in tests rather than by equality. Trivial to add and it improves
every downstream test — happy to send that as a separate PR whenever.

Found in a conformance audit of the VTI stack against DTG Credentials
(OpenVTC/verifiable-trust-infrastructure#1054). Finding F6.