RF-BLOG-02: A DIDComm v2 Mediator in Rust Protocols, Plugins, and Key Management in the Cloud

## RF-BLOG-02 A DIDComm v2 Mediator in Rust

**Type:** Child Story / Blog Post
**Parent:** Epic #515 (#RF-BLOG-01)
**Status:** Ready to draft (pitch as primary)
**Project:** [`adorsys/didcomm-mediator-rs`](https://github.com/adorsys/didcomm-mediator-rs)

### Hook / one-liner
A deep, honest walkthrough of `didcomm-mediator-rs`: implementing DIDComm v2 mediator/pickup/forward/trust-ping protocols as compile-time feature-gated crates, with keys in AWS KMS, secrets in AWS Secrets Manager, and an axum/tokio async message broker backed by MongoDB.

### Why this post
Most concrete and most unique of the four "how we actually built it" engineering content that Rust readers bookmark. Strongest chance of approval.

### Content hints
- Crate-per-protocol **plugin architecture** (`plugin-api`, `web-plugins/*`) and how Cargo features (`routing`, `pickup`, `trust-ping`, `mediator-coordination`) compose the server.
- **Key hygiene**: `ed25519-dalek`, `x25519-dalek`, `subtle` (constant-time), `zeroize` (secret erasure); private keys never in the process (AWS KMS), cached secrets via `aws_secretsmanager_caching`.
- **Async flow**: accept → route → relay → pickup over `axum` + `tokio`; observability with `tracing` (+JSON) and `axum-prometheus`; `tikv-jemallocator`.
- Reusable crate snippets from the repo tangible code wins.

### Acceptance criteria
- [ ] ~1000–1500 words, original
- [ ] ≥1 real code snippet + ≥1 architecture/logic description
- [ ] Explains why Rust (memory safety, async, secret hygiene)
- [ ] Author bio + repo links included

_Part of epic #515 (#RF-BLOG-01)._