Support multi-curve (P-256, P-384, P-521, Ed25519) and RSA keys with unified signing abstraction and aws-lc-rs

## Objective

Implement comprehensive multi-algorithm key loading and signing support for popular elliptic curves (P-256, P-384, P-521, Ed25519) and RSA algorithms when loading signing keys from the filesystem. Introduce a decoupled, consistent cryptographic abstraction interface (`TokenSigner` / `KeyLoader`) for downstream consumers, and replace existing crypto libraries with `aws-lc-rs` in its latest version for accelerated signing operations.

## Context

Currently, the server's key loading and token signing implementations are tightly coupled to ECDSA P-256 (`ES256`) and the pure-Rust `p256` crate:
1. `src/setup.rs` and `src/utils/keygen.rs` only support parsing P-256 EC PEM private keys.
2. `src/server/handlers/status_list/utils/token.rs` directly constructs `p256::ecdsa::SigningKey` and hardcodes the `ES256` algorithm.
3. CWT signing hardcodes COSE algorithm identifier `-7` (`ES256`).
4. Downstream components (`get_status_list.rs`, `cert_manager`, `file_watcher`) lack a stable trait boundary, causing any cryptographic changes to ripple throughout the server.

Real-world deployments require support for broader cryptographic suites:
- **Elliptic Curves**: P-256 (`ES256`), P-384 (`ES384`), P-521 (`ES512`), and Ed25519 (`EdDSA`).
- **RSA**: RSASSA-PKCS1-v1_5 (`RS256`) and RSASSA-PSS (`PS256`) across 2048/3072/4096-bit keys.

Migrating to `aws-lc-rs` (AWS Libcrypto for Rust) in its latest version provides assembly-optimized signing routines, constant-time guarantees, and substantial signing throughput improvements over pure-Rust crates.

*Note: This ticket consolidates and expands upon #476.*

## Deliverables

- [ ] **Cryptographic Abstraction Interface**:
- Define a unified `SigningAlgorithm` enum (`ES256`, `ES384`, `ES512`, `EdDSA`, `RS256`, `PS256`) with mapping to JOSE algorithm strings and COSE integer identifiers.
- Define a clean, decoupled `TokenSigner` trait (`sign_jwt(&self, ...) -> Result`, `sign_cwt(&self, ...) -> Result>`) isolating downstream consumers from low-level crypto primitives.
- [ ] **`aws-lc-rs` Migration**:
- Add `aws-lc-rs` (latest version) to `Cargo.toml` and remove `p256`.
- Implement key parsing and signature generation using `aws-lc-rs` backends.
- Update `supply-chain/config.toml` audits and cargo-vet exemptions.
- [ ] **Filesystem Multi-Key Loading**:
- Support loading PKCS#8 and SEC1/PKCS#1 PEM files for EC (P-256, P-384, P-521), Ed25519, and RSA keys.
- Automatically detect the key type and algorithm from the PEM structure.
- Ensure dynamic hot-reloading via `FileWatcher` works seamlessly with all supported key formats.
- [ ] **Dynamic Token Minting**:
- Dynamically set the JWT `alg` header to match the loaded key's algorithm.
- Dynamically set the COSE algorithm header in CWT (`COSE_Sign1`) tokens (`-7` for ES256, `-35` for ES384, `-36` for ES512, `-8` for EdDSA, `-257` for RS256, `-37` for PS256).
- [ ] **Benchmarking & Testing**:
- Add unit tests verifying token signing and external signature verification for every supported curve and RSA format.
- Benchmark signing throughput before and after to validate performance improvements.

## Acceptance Criteria

- [ ] Private keys in P-256, P-384, P-521, Ed25519, and RSA format load successfully from disk and sign valid JWTs and CWTs.
- [ ] Downstream handlers only depend on the high-level `TokenSigner` interface.
- [ ] `cargo test` passes across all cryptographic and token tests.
- [ ] Signing throughput shows measurable performance gains with `aws-lc-rs`.

## References

- Sub-EPIC: #501 (Sprint 1: Protocol Compliance & Cryptographic Hardening)
- Baseline EPIC: #141 (Status List Server Hardening & Production Readiness)
- Supersedes / Consolidates: #476 (Switch P-256 crate to aws-lc-rs for faster signing operations)