⬆️ chore(deps): upgrade all dependencies to latest majors

[luiscosio]

Raises every dependency in the workspace to its latest released major, and refreshes the lockfile.

Major (incompatible) bumps

16 of 21 direct deps were already on their latest major. Five needed incompatible bumps:

Crate	Old	New
opentelemetry	0.31	0.32
opentelemetry_sdk	0.31	0.32 (0.32.1 locked)
opentelemetry-otlp	0.31	0.32
tracing-opentelemetry	0.32	0.33
sha2	0.10	0.11

Left at their existing (already-latest) majors: tokio 1, rustls 0.23, tokio-rustls 0.26, rustls-pemfile 2, rustls-pki-types 1, x509-parser 0.18, tss-esapi 7, hyper 1, hyper-util 0.1, http 1, http-body-util 0.1, bytes 1, clap 4, tracing 0.1, tracing-subscriber 0.3, anyhow 1.

Security impact

Dependabot alert #1 (medium) is expected to close.

• GHSA-w9wp-h8wv-79jx — opentelemetry_sdk unbounded memory allocation in W3C Baggage propagation. Vulnerable range <= 0.32.0, first patched 0.32.1. Lockfile now pins 0.32.1.

cargo update also picked up transitive fixes that were not separately alerted:

• rustls-webpki 0.103.11 → 0.103.13 — RUSTSEC-2026-0099, RUSTSEC-2026-0098 (name-constraint bypasses), RUSTSEC-2026-0104 (reachable panic in CRL parsing)
• anyhow 1.0.102 → 1.0.104 — RUSTSEC-2026-0190 (Error::downcast_mut() unsoundness)

cargo audit on the lockfile: 3 vulnerabilities before → 0 after. One unmaintained warning remains for rustls-pemfile (RUSTSEC-2025-0134); it is already at its latest release 2.2.0, so there is nothing to bump to.

Code changes required

None. No source files were touched — this PR is only sidecar/Cargo.toml and Cargo.lock.

The opentelemetry 0.31 → 0.32 bump was API-compatible for this codebase. sidecar/src/observability.rs already used the post-0.30 surface (SdkTracerProvider, Resource::builder_empty(), with_batch_exporter, provider.shutdown()), and 0.32 kept those stable. sha2 0.11 kept the Digest/Sha256 trait surface used by sign_p256_sha256 in identity.rs.

Verification

tss-esapi-sys ships no bindings for aarch64-darwin, so it cannot build on an Apple Silicon host — this is pre-existing on main and unrelated to this PR. Verification was therefore run on aarch64-linux in a rust:1.94-trixie container with libtss2-dev, swtpm, and tpm2-tools.

Command	Result
cargo build	pass — Finished dev profile in 3m 38s
cargo build --release --locked	pass — Finished release profile in 33.34s
cargo test	pass — 24 passed; 0 failed; 0 ignored
cargo clippy --all-targets -- -D warnings	1 error, pre-existing and identical on main (see below)
cargo audit	0 vulnerabilities (was 3 on main)

The full test suite passes, including identity::tests::simulated_tpm_signer_signs_tls_message, which spawns a real swtpm emulator and exercises TPM-backed P-256 signing.

Known pre-existing clippy failure (not introduced here)

error: use of a fallible conversion when an infallible one could be used
   --> sidecar/src/identity.rs:259:5
    |
259 |     KeyHandle::try_from(loaded).context("converting TPM handle to key handle")
    |     ^^^^^^^^^^^^^^^^^^^ help: use: `From::from`

This reproduces byte-for-byte on unmodified main, and it is in tss-esapi usage — a crate this PR does not bump. Left out of scope to keep this a pure dependency PR; worth a one-line follow-up.

The repo has no .github/workflows/, so there were no CI commands to mirror.

---

Follow-up commit: clippy fix (48b4884)

Fixes a pre-existing clippy error on main, deliberately excluded from the dependency commit above to keep that diff scoped to dependencies.

sidecar/src/identity.rs:259 used KeyHandle::try_from(loaded).context(...). Converting ObjectHandle -> KeyHandle is infallible, so the fallible conversion plus the anyhow::Context wrapper was dead error handling. clippy's unnecessary_fallible_conversions makes this a hard error under -D warnings, and this crate escalates further with [lints.clippy] pedantic = "deny".

-    KeyHandle::try_from(loaded).context("converting TPM handle to key handle")
+    Ok(KeyHandle::from(loaded))

The function still returns anyhow::Result<KeyHandle> — the two earlier ? operations are genuinely fallible. One line, no behaviour change.

Verification

cargo build cannot run on aarch64-darwin at all: tss-esapi-sys ships no bindings for that target, and this fails identically on unmodified main, so it is environmental rather than a regression. Verified on aarch64-linux in rust:1.94-trixie with libtss2-dev, pkg-config, clang, cmake, swtpm, swtpm-tools, tpm2-tools:

Command	Result
cargo clippy --all-targets -- -D warnings	exit 0, clean
cargo test	24 passed, 0 failed, 0 ignored

Run against this branch (dependency upgrades + fix), not against main — so clippy is clean against the upgraded dependency versions that actually ship here. The suite includes identity::tests::simulated_tpm_signer_signs_tls_message, a real swtpm-backed TPM P-256 signing test.