v0.9.4

**Patch release — DTLS-SRTP on the inbound delayed-offer offer (RFC 5763).** Piece B of DTLS-on-delayed; **completes SRTP for delayed offer** (SDES + DTLS, both directions).

### Added
- **DTLS-SRTP on the inbound delayed-offer offer.** On an inbound delayed offer SiphonAI is the *offerer*, so with `[media].srtp` `preferred`/`required` and the new **`[media].srtp_offer = "dtls"`** it now **offers** DTLS-SRTP in the 200 OK (`UDP/TLS/RTP/SAVPF` + `a=fingerprint` + `a=setup:actpass`); the peer's answered fingerprint + setup arrive in the ACK, where SiphonAI derives its role (RFC 5763 §5) and enables the handshake. Surfaces on `start.srtp` (`exchange: "dtls"`). This is a new capability — SiphonAI had only ever *answered* DTLS.

  `[media].srtp_offer` defaults to `"sdes"` (the 0.9.2 behaviour) and only affects the delayed-offer path; inbound early offer always *answers* the peer's choice.

Verified live: `[media].srtp = "required"` + `srtp_offer = "dtls"` + an offerless INVITE → the 200 OK offers DTLS (`a=fingerprint`), the peer answers DTLS in the ACK, the handshake is enabled, and the call bridges. New SIPp `delayed_offer_dtls` phase.

**SRTP for delayed offer is now complete** — SDES + DTLS, both directions: **0.9.1** (outbound SDES answer) → **0.9.2** (inbound SDES offer) → **0.9.3** (outbound DTLS answer) → **0.9.4** (inbound DTLS offer).

PR: #196.

🤖 Generated with [Claude Code](https://claude.com/claude-code)