docs: fix three stale implementation status claims

All three were written before the work was done and never updated:

1. README Known Limitations and SPEC.md §Revocation — Auditability both said
   'Java issuer does not yet emit the revoc: extension line'. Java has emitted
   it since PR #51 (feat/revoc-auditability). Updated to: all four issuers
   emit the line; all four verifiers parse it; active enforcement is advisory.

2. SPEC.md Open Questions section said 'Revocation auditability: deferred to
   v2' as if the artifact hash commitment was not built. It was built in PR
   #51. Updated to: tamper-evident commitment implemented; full auditability
   (hard verifier enforcement + public revocation log) still deferred.

3. IMPLEMENTERS_GUIDE.md §Mode 0 payload size section said 'Mode 0 is not
   yet implemented in this reference SDK'. Mode 0 was implemented in PR #46
   across all four SDKs. Updated to describe what is implemented.

Author: Ryan Hurst

IMPLEMENTERS_GUIDE.md

@@ -665,7 +665,7 @@ Mode 0 payloads are significantly larger. With ECDSA P-256 and two witness
 cosignatures, a minimal Mode 0 payload is around 700 bytes. With ML-DSA-44,
 Mode 0 is not feasible within QR capacity limits.
 
-Mode 0 is not yet implemented in this reference SDK.
+Mode 0 is fully implemented in all four reference SDKs (Go, TypeScript, Rust, Java). Issuers embed the root hash, issuer signature, and witness cosignatures directly in the payload; verifiers reconstruct the checkpoint body from these fields and verify all signatures without any network access.
 
 ### Payload size implications
 

README.md

@@ -232,7 +232,7 @@ These are genuine gaps that should be addressed before production use. They are
 
 **Revocation delay.** When an entry is revoked, the revocation is effective only once a new checkpoint has been issued and the verifier's cached artifact becomes stale (STALE_THRESHOLD=32 entries). Between revocation and cache expiry, a revoked credential may still pass verification. This is an inherent trade-off in transparency log models — the window is bounded by checkpoint frequency and STALE_THRESHOLD, not unbounded. Deployments with strict revocation requirements should set short checkpoint intervals and tune STALE_THRESHOLD accordingly.
 
-**Revocation auditability partially implemented.** The Go, TypeScript, and Rust issuers commit `revoc:<hex(SHA-256(artifact))>` as a 4th extension line in each checkpoint body. This line is covered by the issuer signature and witness cosignatures, so every witnessed checkpoint also attests to the revocation state at that moment. Two steps remain: the Java issuer does not yet emit the `revoc:` line, and no verifier currently cross-checks the committed hash against the artifact it fetches. Until verifier enforcement is complete, the commitment is present in the signed checkpoint but not verified end-to-end. See SPEC.md §Revocation — Auditability for the full status and remaining work. Relying parties requiring independently auditable revocation should note this.
+**Revocation auditability implemented (tamper-evident, not fully auditable).** All four SDK issuers (Go, TypeScript, Rust, Java) commit `revoc:<hex(SHA-256(artifact))>` as a 4th extension line in each checkpoint body. This line is covered by all signatures — the issuer signature and all witness cosignatures — so every witnessed checkpoint attests to the revocation state at that moment. All four verifiers parse the `revoc:` line when present. Active cross-checking of the committed hash against the fetched artifact is advisory (logged but not enforced as a hard rejection) — the commitment is present and signed but not yet a mandatory verification step. See SPEC.md §Revocation — Auditability for the full model and what full auditability would additionally require.
 
 **Revocation is implemented** in all four language SDKs (Go, TypeScript, Rust, Java). Issuers serve a signed Bloom filter cascade at `GET /revoked` and accept `POST /revoke` for demo purposes. Verifiers fetch the artifact on cache miss, verify the issuer signature with algorithm binding, apply a staleness check (STALE_THRESHOLD=32 entries), and query the cascade fail-closed. The cascade algorithm is cross-verified against locked test vector bytes in all four languages. See SPEC.md §Revocation for the normative wire format and construction parameters.
 

SPEC.md

@@ -1499,15 +1499,16 @@ checkpoint signature automatically covers the revocation state at that moment.
 Witnesses attest to the revocation state without any change to the witness
 protocol.
 
-The Java issuer does not yet emit the `revoc:` extension line. No verifier
-currently cross-checks the hash in a checkpoint against the artifact it fetches,
-so the commitment is present in signatures but not yet enforced at verification
-time. The remaining steps to complete this are:
-
-1. Java issuer: emit `revoc:<hex>` as checkpoint body line 4
-2. All verifiers: after fetching the revocation artifact, compute
+All four issuers (Go, TypeScript, Rust, Java) now emit the `revoc:` extension
+line when a revocation artifact is available. All four verifiers parse the line
+and extract the hash. Active enforcement — rejecting a verification result when
+the hash of the fetched artifact does not match the committed hash — is currently
+advisory in all four verifiers (the hash is extracted and available but not used
+as a hard rejection criterion). The remaining step to complete this is:
+
+1. All verifiers: after fetching the revocation artifact, compute
    `SHA-256(artifact_bytes)`, find the `revoc:` line in the checkpoint body,
-   and reject if the hashes do not match
+   and reject if the hashes do not match (currently logged only)
 
 Once step 2 is complete, a verifier that checks both the checkpoint signature
 (covering the revoc hash) and the fetched artifact against that hash has an
@@ -2218,11 +2219,7 @@ signature verification, staleness check, and cascade query — fail-closed
 throughout. The cascade construction follows SPEC.md §Revocation normative
 parameters, not the CRLite wire format. Delta updates are deferred to v2.
 
-**Revocation auditability: deferred to v2.** The current protocol has no
-mechanism for independent verification that the issuer's filter correctly
-reflects all revocations made. A v2 extension would commit a hash of the
-revocation artifact into each checkpoint body, making the revocation state
-tamper-evident and verifiable by witnesses. See §Revocation — Auditability.
+**Revocation auditability: tamper-evident commitment implemented; full auditability deferred.** All four issuers now commit `SHA-256(artifact)` in every checkpoint body as a `revoc:` extension line, making the revocation state tamper-evident. Witnesses automatically cosign this commitment. What remains deferred: hard enforcement in verifiers (currently advisory), and full CRLite-style auditability where independent parties can reconstruct the filter from publicly disclosed revocation events. See §Revocation — Auditability.
 
 ### Non-Blocking — Required Before v1 Finalization