fix(init): subordinate first-boot must not stall when revocation_base_url is set before establishment

[Bugs5382]

What

Adopting an intermediate/issuing node with revocation_base_url set in its initial config leaves the node booting but never binding its management API — the adopt orchestration times out. Removing the revocation config lets the same node reach the awaiting-certificate state normally (confirmed by A/B: identical config minus revocation_base_url boots and serves).

A subordinate is not a CA until its enrollment is signed, so bringing up the revocation surface (CRL/OCSP listener + delegated OCSP responder) at first boot — before any CA key/identity exists — is premature and wedges the boot.

Expected

First-boot should not stand up the revocation surface (or run OCSP-responder ensure) until the node has an established identity; a pre-establishment revocation_base_url should be inert (or the bring-up deferred), never blocking the management listener.

Repro

Adopt a role=intermediate node with pki.revocation_base_url set and no allow_unverified_revocation_url; the node boots (NIC up) but :443 never listens. Same config without revocation_base_url → awaiting-certificate, :443 serving.

Workaround shipped web-side (CryptOS-PKI/web#73): the adopt wizard no longer sends revocation config for a subordinate.

[Bugs5382]

Not reproducible — closing as works-as-designed.

Captured a verbose serial (console ISO) while adopting an intermediate with pki.revocation_base_url set and no allow_unverified_revocation_url — the exact config suspected of bricking the boot. The node boots into running mode normally, reaches awaiting-certificate, and serves its management API. With a revocation URL set on a subordinate that has no CA identity yet, it logs non-fatal errors and continues:

revocation preflight: /crl returned 500 (CDP/AIA issuance blocked unless allow_unverified_revocation_url is set)
OCSP responder: no CA key material (ceremony not committed)

The revocation preflight is a goroutine and the OCSP-responder ensure only logs on error, so neither blocks the boot or the listener — matching the code comments in internal/init/run.go. The originally observed hang was a one-off; it does not reproduce from the revocation config.

The web-side change to omit revocation config for a subordinate at adopt time (CryptOS-PKI/web#76) stands as a reasonable UX cleanup — a subordinate is not a CA until its enrollment is signed, so carrying a revocation URL there only produces these noisy non-fatal errors until it is established — but it was not fixing a boot failure.