TEE registrar page describes the pre-cutover registration flow

The TEE registrar spec page describes the registration flow as it worked before two recent cutovers, so a couple of things on it no longer match the code.

Page: `docs/base-chain/specs/protocol/proofs/registrar.mdx`

**1. The ZK-proof-of-attestation workflow is gone.**

The page lists this under Responsibilities:

> 4. Generate a ZK proof of attestation correctness for every enclave that is not yet registered.

and this under dependencies:

> - a proving backend (Boundless marketplace or a self-hosted RISC Zero prover)

[base/base#4425](https://github.com/base/base/pull/4425) (merged Aug 14) replaced that with direct hinted Nitro registration and, in its own words, "removes all active Registrar construction and invocation of Boundless proof clients". The same PR says the registrar now discovers `NitroValidator` / `CertManager` through the Registry and "uses issuer/serial CertManager identities for revocation".

That also affects the payload section further down, which describes `output` as the `VerifierJournal` consumed by `NitroEnclaveVerifier.verify()` during `registerSigner()`, and the Layer 1 revocation section, which describes `revokedCerts(certPathDigest)` keyed by path digest rather than issuer/serial.

**2. The `NitroEnclaveVerifier.sol` link 404s.**

The page links to it twice (in the intro and in the contract-calls table):

```
https://github.com/base/contracts/blob/main/src/L1/proofs/tee/NitroEnclaveVerifier.sol
```

[base/contracts#400](https://github.com/base/contracts/pull/400) (merged Aug 12) deleted that file along with `INitroEnclaveVerifier.sol`.

**What I'm not doing**

I'm not sending a PR for this because I can't tell from outside what the page should say now. `crates/proof/tee/registrar/src/cert_manager.rs` still holds a `NitroEnclaveVerifierClient`, and `crates/proof/tee/nitro-verifier/src/types.rs` still says its types are "inlined from the contracts repo's `INitroEnclaveVerifier.sol`" — the interface that was just removed. So the migration looks like it's still in flight and only you know where it lands.

Happy to write the PR once you tell me the intended end state, or to just fix the dead link on its own if the rest is staying as is for now.