feat(tls): add crash-safe ACME HTTP-01 issuance

[bymoye]

Refs #31. Depends on #34. Related server capability work: nazozero/NazoAuth#130

Outcome

Adds the independently reviewable ACME HTTP-01 issuance transaction on top of the external TLS certificate provider. This PR issues and validates deployment-owned public-server certificate material; it deliberately does not install, reload, or claim that a live endpoint changed certificates.

Security and recovery boundary

• requires the negotiated proxy_tls deployment grant and binds deployment/declaration revision, tenant, exact hostname, JTI, issuance revision CAS, configuration/trust digests, capability, and expiry;
• accepts one exact DNS identifier only; wildcard/IP orders and unknown schema fields fail closed;
• requires explicit --agree-terms for the exact configured HTTPS TOS URL and a preconfigured non-symlink HTTP-01 webroot;
• persists the ACME account private key before any CA request, then uses the same key for create-or-return-existing recovery; account credentials and the server private key remain owner-only controller/deployment secrets;
• snapshots the ACME config, optional directory CA, TLS provider config, and provider trust anchors so recovery does not re-trust mutable external files;
• journals the challenge path/digest before publication, persists the server key/CSR before finalization, resumes the server-issued order URL, and bounds the complete async transaction by durable expiry;
• validates the returned chain, exact SAN, serverAuth usage, minimum validity, and private-key match offline before committing an issuance receipt;
• removes only the digest-matching challenge, idempotently finalizes receipt/audit after a crash, and archives/clears expired pending transactions without presenting them as success.

NazoAuth protocol keys remain in NazoAuth/KMS. Client and wallet private keys remain client-side. No NazoAuth release version or Direct TLS capability is hard-coded.

Responsibility choice

First-principles review kept ACME issuance separate from #34's install/reload/public-verification transaction. Combining them would couple two independently recoverable external systems and create ambiguous rollback ownership. The issuance receipt instead supplies exact certificate/key paths and digests to the existing provider transaction. Nginx/Angie configuration, Direct TLS negotiation, and NazoAuth transport mutation remain outside this PR until the server exposes the required capabilities from NazoAuth #127/#128/#129/#130.

Verification

Local Windows, exact commit 621298f:

• cargo fmt --all -- --check
• git diff --check
• cargo clippy --workspace --all-targets --all-features --locked -- -D warnings — no issues
• cargo test --workspace --all-targets --all-features --locked — 361 passed
• cargo build --locked --workspace --all-targets --all-features --release — 0 errors; three informational MSVC import-library linker messages
• release-binary top-level and tls --help smoke

Focused tests cover strict parsing, exact challenge cleanup/tamper refusal, account-key pre-network persistence and journal binding, aborted transaction evidence/pending retirement, receipt binding, and issuance revision fencing.

Not yet verified / not claimed

• no real CA account/order or public HTTP-01 validation was run;
• no real certificate installation, reload, public TLS switch, Nginx/Angie configuration, Direct TLS change, remote deployment, or rollback was run;
• exact head 621298f8535d37c1ed2f3bb0d6389bb0b2545fa8 passed 13/13 remote checks on Windows, macOS, Ubuntu, controller/server compatibility, and the Docker/Podman/systemd discovery job; Linux owner/mode behavior is covered by CI, but no real CA or deployed endpoint was exercised;
• no OIDF Suite execution is part of this TLS stage.

No merge, release, deployment, or tag operation is performed by this PR.