feat: set credentialStatus on a credential being built; PartialEq on the type

[stormer78]

The two items from the conformance audit in #10 that the Working Draft 02 work
closed without.

credentialStatus can be set on a credential being built

DTGCommon::credential_status has been modelled since 0.7.0, but only so that an
entry already on the wire survived a parse-then-re-serialise without changing the
credential's digest. A credential built by one of the new_* constructors had no
way to acquire one short of reaching through credential_mut.

with_credential_status and set_credential_status sit alongside the existing
with_id/set_id pair and carry the same before-signing caveat — a Data
Integrity proof covers the credential minus its proof, so a status entry
spliced in after sign() leaves a document whose proof no longer verifies.

It is CONDITIONAL, not REQUIRED — which is why it is a setter

The audit asked for this as a REQUIRED constructor parameter on new_vdc,
reading the VDC draft (dtgwg-cred-spec#19). The text that merged makes it
conditional:

A VDC MUST carry credentialStatus where its validity period exceeds the
freshness window the governing VTC or VTN defines for delegations, and MAY omit
it otherwise. Issuers SHOULD prefer short validity and re-issuance wherever the
delegator is reachable […]

A verifier must be able to establish that an appointment is in force without
contacting the delegator, and two things satisfy that: a validUntil short
enough that expiry alone bounds the exposure, with the delegator withdrawing by
declining to re-issue; or a status entry the verifier can check.

That freshness window is governance this library does not know, so nothing here
can decide which side of the condition a given VDC falls on. Demanding the entry
from every caller would forbid the short-validity case the specification prefers
— and prefers for a stated reason: a status check is a live lookup that reveals
the verification event to whoever hosts the status list. So the constructor still
supplies no entry of its own, and a caller that needs one attaches it.

Worth flagging to whoever runs the VTI-side audit: F6 has this as REQUIRED, and
the same reading may have propagated into the stack.

Still not resolved anywhere

Neither delegation::verify_chain nor authority::verify_chain checks
revocation; both verify structure, scope and validity only. Unchanged here —
revocation remains a live lookup the caller performs.

PartialEq on DTGCredentialType

Unrelated and one line. Consumers had to assert by pattern (matches!);
assert_eq! now works and reports the actual variant on failure. Eq is derived
alongside. The deprecated RCard variant provokes no warning from the derive.

Notes

• Non-breaking — both changes are additive, so no major bump. Left under
  [Unreleased] at 0.8.0 rather than cutting a release.
• 121 tests, up from 118: that the constructor invents no status entry (omitting
  is legitimate), that an attached one reaches the wire and survives parsing
  back, that set_ matches the builder, and that types compare by equality. Plus
  a doctest. cargo clippy --all-targets and cargo fmt --check are clean.
• README gains a "Revocation status" section next to "Credential identifiers".

Refs: #10

[affinidi-appsecurity-bot]

🛡️ AI Agentic Security Code Review

🔎 A manual security review is recommended before merging. Please contact the Security team for specifics and remediation guidance.

ℹ️ Detailed findings are not published on public repositories; the Security team holds the complete report.