Phases 4 and 6 of the credential revocation plan
(src/oid4vc/REVOCATION_PLAN.md), completing the stack.

WHY THIS IS NOT AN OPTIMISATION

CredentialAuthGuard verifies a credential on every wallet request, and every
verification dereferences the status list. Without this change each wallet
call makes a loopback HTTP request, and wallet authentication as a whole comes
to depend on the process being able to reach itself at its own advertised
hostname. In a container whose OID4VC_BASE_URL is an external name, that
resolves somewhere else or nowhere, and every request 401s.

Oid4vcStatusService now replaces Credo's status list fetcher at boot: URIs
under our own statusListBaseUrl are answered from Vault directly, everything
else is delegated to the original fetcher untouched. Since the manager is the
only party checking status today, this is the enforcement path that actually
runs; the HTTP endpoint exists for third-party verifiers.

Two Credo internals were checked before relying on them, because either being
false would have made the patch a silent no-op:

- SdJwtVcService is registered with registerSingleton (SdJwtVcModule.js:24),
  so dependencyManager.resolve returns the instance agent.sdJwtVc.verify uses.
- getBaseSdJwtConfig calls getStatusListFetcher afresh on every sign and
  verify, so replacing the method affects later verifications rather than
  being captured once at construction.

getStatusListFetcher is private in the type declarations, so the patch casts.
That is deliberate: Credo exposes no supported hook for supplying a fetcher,
and the alternative is making wallet auth depend on server self-reachability.
If a Credo upgrade breaks it, onModuleInit warns and the system falls back to
HTTP rather than failing to boot.

Only a single clean path segment is claimed as ours; a nested path or query
string under our own base URL falls through to the network rather than being
guessed at.

DOCS

README gains the three status endpoints, a Revocation section with curl
examples, and the status list records under Storage. TRUST_MODEL no longer
calls the mutable on-chain document a "revocation surface" - it is a
key-rotation surface, and rotating invalidates every credential for every
holder. Per-credential revocation is recorded as its own invariant, along with
the gap that credentials predating the status claim can never be revoked.

TESTS

216 -> 228. The new cases cover URI matching in both directions, a revocation
being reflected immediately, autoInit=false leaving the fetcher untouched, and
an unavailable agent warning rather than failing boot.

Phase 3 of the credential revocation plan (src/oid4vc/REVOCATION_PLAN.md).
This is the half that makes the pointers embedded by PR 1 resolve: until now
the app issued credentials referencing a URL nothing served.

- GET credential/status/list/:listId - public, because verifiers dereference
  it and @sd-jwt fails verification outright if it cannot.
- POST credential/status/revoke and .../reactivate - manager JWT, inherited
  from the global AuthGuard, addressed by issuance session id.

THE LIST ROUTE WRITES ITS OWN RESPONSE

It takes @Res() and calls response.end(token) rather than returning a string.
@sd-jwt's default status list fetcher compares Content-Type for strict
equality with application/statuslist+jwt, but Express appends "; charset=utf-8"
to any string body, and Nest sends any object - a Buffer included - through
response.json(). Neither ordinary return path can produce an exact media type.

This matters because Credo's own fetcher does not check the media type at all.
Served the obvious way, the endpoint works for every internal caller and fails
only for third-party verifiers - the audience the endpoint exists for. Caught
by the e2e, which deliberately uses @sd-jwt's default fetcher rather than a
stub. Nothing is written before the await, so a thrown NotFoundException still
renders through the exception filter.

TESTS

209 -> 216 unit tests, plus a new offline e2e suite.

test/status-list.e2e-spec.ts stands alone: no Vault, no chain, no separately
running server. The app really listens, Vault KV is a Map with JSON
round-tripped writes, and Vault transit signing is a real Ed25519 key from
node's crypto - so the credential and the status list are signed by the same
key, which is what Credo requires. It issues a genuine SD-JWT VC, verifies it
over real HTTP, revokes it, and asserts verification then fails with "Status
is not valid" while a second credential still verifies.

It needs no infrastructure, so it runs locally with a path filter -
`yarn test:e2e status-list` - and in CI as part of the existing yarn test:e2e
step, which already has LocalNet, Vault and the compose stack up. No second
jest config: e2e specs live in test/ alongside app.e2e-spec.ts.

Phases 0-2 of src/oid4vc/REVOCATION_PLAN.md. Credentials issued by this
service were bearer-forever: nothing emitted a status claim, no endpoint
served one, and neither verification path checked revocation. Withdrawing one
holder's access meant rotating the issuer key, which invalidates every
credential ever issued for everyone.

This lands the issuance half. Credentials now carry an IETF Token Status List
pointer, and the machinery exists to flip a bit. The HTTP endpoint that serves
the list does not exist yet (Phase 3).

WHAT IS HERE

- @sd-jwt/jwt-status-list promoted from a transitive dependency to a direct
  one, pinned exactly to the version yarn.lock already resolves, so the
  lockfile is untouched.
- Oid4vcConfig.statusListBaseUrl / statusListUri. The URI is baked into every
  credential at issuance and a failed status fetch fails the entire
  verification, so statusListBaseUrl warns when OID4VC_BASE_URL carries no
  path segment - the realistic misconfiguration that would render every
  credential issued under it permanently unverifiable.
- StatusListRecord: one Vault KV record per list, holding a fixed-size
  bitstring plus the next free index, pre-sized at 16384 entries (36 bytes
  once deflated). Size is a constant, not configuration.
- Oid4vcStatusService: allocates entries at issuance, flips bits on
  revoke/reactivate, and serves the list as a signed statuslist+jwt.
- The SD-JWT branch of the credential mapper reserves a bit and records the
  (list, index) pair on the local issuance session before returning anything
  signed.

WHY IT IS SHAPED THIS WAY

The status list token is signed with the manager transit key because Credo
configures a single verifier for both a credential and its status list
(SdJwtVcService.js:154). A list signed by any other key fails verification.
This is a constraint, not a preference.

The token carries no exp. @sd-jwt only checks expiry when the claim is
present, and an expired list fails every credential pointing at it - an
availability cliff bought for nothing, since the token is regenerated on
every write.

Every read-modify-write runs through one in-process queue, token building
included. Building outside the queue lets a revocation land between reading
the record and populating the cache, which would publish and then keep
serving a token saying a revoked credential is live.

The status claim is set after the claims spread so a same-named claim in
issuanceMetadata cannot shadow the real revocation pointer, and it is kept
out of the disclosure frame because status is reserved by SD-JWT VC and
listing it in _sd makes the library throw.

Allocation, persistence, then signing - in that order. A failure at either of
the first two aborts issuance, because a credential whose entry was not
recorded could never be revoked.

The W3C JwtVc branch is deliberately untouched. Credo hardcodes 'Verifying
credential status is not supported for JWT VCs', so a credentialStatus there
would break verification rather than enable it.

DO NOT DEPLOY THIS COMMIT ALONE

Credentials issued from here point at a URL nothing serves until Phase 3.
A failed status fetch throws, so any credential issued in between is
permanently unverifiable. Related: credentials issued before this change
carry no status claim at all, so they remain valid forever and cannot be
revoked - @sd-jwt skips the check entirely when the claim is absent. Reissue
at cutover if any of them matter.

TESTS

24 suites / 190 tests before, 26 / 209 after. No existing test was changed.
oid4vc-status.service.spec.ts signs with a real Ed25519 key from node's
crypto, so the published token is verified the way a verifier would rather
than merely inspected. oid4vc-issuer.service.spec.ts is new - the issuer
service had no spec, so the mapper was untested in both branches.

Writing those tests surfaced a pre-existing defect, recorded in the plan but
deliberately not fixed here: the W3C JwtVc branch silently drops every custom
claim, because Credo's W3cCredentialSubject only maps id and claims. The test
pins the current behaviour rather than endorsing it.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>