fix(build): repair the rcgen 0.14 break and pin the TLS provider

[rsantacroce]

main does not currently produce a node that runs, for two unrelated reasons.

1. lib does not compile

The rcgen 0.13 → 0.14 bump (#128) renamed CertifiedKey::key_pair to signing_key, and lib/net/mod.rs still used the old name:

error[E0609]: no field `key_pair` on type `rcgen::CertifiedKey<rcgen::KeyPair>`
   --> lib/net/mod.rs:118:32
    = note: available fields are: `cert`, `signing_key`

Nothing caught it because the check-lint job runs clippy before cargo check, and clippy has been failing on every recent run for an unrelated nightly regression. The compile error merged behind a job that was already red.

2. The node panics at startup, depending on how you built it

configure_server and configure_client build their rustls configs from the process-level provider. lib asks for ring and nothing here wants anything else — but Cargo unifies features across a build, and --all-targets also compiles integration_tests, whose chain (bip300301_enforcer_lib → bdk_electrum → electrum-client) turns on aws-lc-rs. rustls then sees two providers, refuses to guess, and panics on the first config built.

That first config is make_server_endpoint, so the symptom is a workspace that builds without a warning and a node that dies on startup:

thread 'main' panicked at rustls-0.23.40/src/crypto/mod.rs:249:14:
Could not automatically determine the process-level CryptoProvider from Rustls crate features.

cargo build is fine. cargo build --all-targets is not. That difference is a memorable afternoon, and it also makes the integration suite fail 10/10 if you build that way first.

The fix

coinshift::install_default_crypto_provider() chooses explicitly, and main calls it first thing, so the binary no longer depends on who else is in the build graph.

Verification

• cargo build --workspace --all-targets — clean
• cargo fmt --all --check, cargo clippy --workspace --all-targets — clean
• 55 unit tests pass
• Integration suite: 10/11 pass. swap_creation_open_fill fails on main too, before these changes — see the issue filed separately.
• tls_configs_build_once_a_provider_is_installed pins the second fix: remove the install_default_crypto_provider() call and it reproduces the panic exactly.

🤖 Generated with Claude Code

https://claude.ai/code/session_01Mrg9zkV9bEdAvVEjx1RKLx