fix(proof-vm-agent): install rustls provider at boot, drop aws-lc-rs (Architecte follow-up 1/4)

[echobt]

Summary

Architecte / Owner follow-up 1 of 4 (CryptoProvider — agent boot stable) before Proof FC wires on prod. Fixes the proof-vm-orchestrator boot panic that forced staging to keep a previously built binary; that workaround is retired.

Root cause (reproduced locally, not guessed). rustls only auto-selects a CryptoProvider when exactly one of its ring / aws-lc-rs features is on. Cargo unifies features across every package selected for a build, so cargo build --workspace or cargo build --bin proof-vm-orchestrator from the workspace root (which resolves features over all members) compiled rustls with both: reqwest → ring, axum-server's tls-rustls → aws-lc-rs. RustlsConfig::from_pem_file then panicked at the first HTTPS listener:

Could not automatically determine the process-level CryptoProvider from Rustls crate features.
Call CryptoProvider::install_default() before this point …

Only a package-scoped cargo build -p proof-vm-orchestrator-bin happened to work.

Fix (bins/proof-vm-orchestrator)

• install_crypto_provider(): install ring explicitly as the process-level provider before any TLS config exists; a repeat / pre-existing provider is a no-op, never a panic. Logged at boot: rustls crypto provider selected provider=ring installed_here=….
• axum-server → tls-rustls-no-provider + a direct rustls dep on ring. aws-lc-rs / aws-lc-sys (cmake + C toolchain) leave the binary's graph entirely, so every build shape now unifies to the same single provider and the musl build is a plain cargo build.
• tls_config() split out so the PEM → server-config step is unit-testable.
• Smoke test crypto_provider_installs_once_and_tls_boots_from_pem: install twice, ServerConfig::builder() (the panic site), then load a self-signed PEM pair (rcgen, dev-dep only) into the server config.

Docs (docs/runbooks/proof-vm-orchestrator.md) — new § Build: exact flags for glibc and static musl (CC_x86_64_unknown_linux_musl=musl-gcc, because ring looks for x86_64-linux-musl-gcc), a no-KVM listen smoke to run before install, and the boot-log lines to expect; "a panicked line is a bug, never something to work around by keeping an older binary".

No wire / protocol / env change. No digest anywhere. Lockfile: rcgen + its closure (dev-only); aws-lc-rs is no longer in any built graph (cargo tree --workspace -i aws-lc-rs → none).

How to verify

# 1. the exact staging shape that panicked, now boots
cargo build --release --bin proof-vm-orchestrator          # from the workspace root
d=$(mktemp -d) && openssl req -x509 -newkey ec -pkeyopt ec_paramgen_curve:prime256v1 -nodes \
  -keyout $d/k.pem -out $d/c.pem -subj /CN=smoke -addext subjectAltName=IP:127.0.0.1 -days 1 2>/dev/null
echo smoke > $d/token
timeout 3 target/release/proof-vm-orchestrator --bind 127.0.0.1:18200 --token-file $d/token \
  --tls-cert $d/c.pem --tls-key $d/k.pem \
  --kernel-digest sha256:$(printf 'a%.0s' {1..64}) --sister-image-digest sha256:$(printf 'b%.0s' {1..64}) \
  2>&1 | grep -E 'crypto provider selected|listening \(https\)|panicked'
# → "rustls crypto provider selected" + "proof-vm-orchestrator listening (https)"; no "panicked"

# 2. package-scoped and musl shapes
cargo build --release -p proof-vm-orchestrator-bin
CC_x86_64_unknown_linux_musl=musl-gcc cargo build --release -p proof-vm-orchestrator-bin --target x86_64-unknown-linux-musl

# 3. unit smoke
cargo test -p proof-vm-orchestrator-bin

Verified here: the root --bin build reproduced the panic on main and boots HTTPS on this branch (curl health → 200 with bearer, 401 without); glibc release and static-pie musl release both boot.

Greptile

• Greptile has reviewed this PR; findings are fixed or answered
• If the bot was silent, I commented @greptileai review

Test plan

• cargo test --workspace
• cargo fmt --all -- --check
• cargo clippy --workspace --all-targets -- -D warnings, cargo deny check, xtask loc-cap / consensus-lint / spec-check / design-check / external-docs-check (compose-matrix assertion needs docker; not touched by this PR)

Risk

Deploy only: the host-installed agent binary. No miner CVM measurement, signature domain, or emission impact. TLS behaviour is unchanged except that boot no longer panics; the provider (ring) is the one every other workspace binary already uses.

Naming

I did not rename BASE_* environment variables, deployed host paths
(/opt/base, /run/base, …), GHCR baseintelligence/base package names, or
base-*-v1 cryptographic domain tags, unless this PR’s purpose is a coordinated
cutover documented in docs/NAMING.md.

  

[echobt]

@greptileai please review CryptoProvider fix (Architecte GO conditionnel).

[greptile-apps]

Greptile Summary

This change makes proof-vm-orchestrator TLS startup explicitly install rustls’s ring crypto provider before building TLS configuration. It switches axum-server to the no-provider rustls feature, adds a direct rustls dependency configured for ring, adds a self-signed-certificate TLS boot smoke test, and documents glibc and static-musl build and startup checks.

Confidence Score: 5/5

Safe to merge.

There are no outstanding findings.

_{Reviews (2): Last reviewed commit: "fix(proof-vm-agent): install rustls prov..." | Re-trigger Greptile}