Add a parity test asserting the vault public route and resolver render byte-identical public views

[LKSNDRTMLKV]

Background

There are currently two independent code paths that both claim to serve "the public view" of a passport: the resolver (renders from the signed publicJwsSignature payload) and the vault's public_read_handler (renders a redacted live row). See #27 for the divergence this causes. Nothing currently asserts these two outputs agree.

Proposal

Add a test (in the spirit of the existing port-inventory-style structural tests) that, for a given published passport fixture, asserts the vault's /public/dpp/{id} response and the resolver's /dpp/{id} response are byte-identical (modulo any fields explicitly expected to differ, if any). This closes the frozen-proof/live-row divergence mechanically and prevents it regressing silently in future — cheaper than remembering to check by hand every time either handler changes.

Found during a 2026-07-18 full-codebase review; filed as a follow-up to #27.

[LKSNDRTMLKV]

Still open — the test does not exist — but the background above is now obsolete and would mislead whoever picks this up.

The premise was "two independent code paths": the resolver rendering from the signed payload, the vault rendering a redacted live row. That divergence is gone (#27, closed). public_read_handler serves the decoded payload of publicJwsSignature via signed_public_view, and the resolver receives that same payload and re-attaches the proof (crates/dpp-resolver/src/handlers/resolve_json.rs:86). The two agree by construction rather than by coincidence.

That lowers the severity from "a real divergence nothing catches" to "an invariant nothing pins". The test is still worth having for exactly the reason originally given — it is cheaper than remembering to check by hand whenever either handler changes — but it is now a regression guard, not a bug hunt.

One note for whoever writes it: publish_serve_cycle.rs deliberately asserts only the vault half and leaves the resolver half to that crate's own tests, to avoid standing up two services in one test. A genuine parity test has to either accept that cost or drive both renderers as library calls over a shared fixture.