fix: don't propagate envelope-managed headers onto a chained OutboxResponse (F5-01/F5-02)

[lesnik512]

What

When propagate_inbound_headers=True, the subscriber copied the inbound row's full header dict onto a handler's OutboxResponse — including the envelope-managed content-type and correlation_id.

A chained OutboxResponse re-encodes through _encode_payload, which re-derives content-type from the new body and reads correlation_id from the dedicated field. The propagated inbound values then collided there, raising ValueError and nacking the successful inbound row to retry-exhaustion on:

• any cross-content-type relay (e.g. inbound str→text/plain, response dict→application/json) — F5-01 (audit-rated High)
• any relay where the handler set an explicit OutboxResponse(correlation_id=...) — F5-02 (Medium)

Found by the 2026-06-14 pass-3 deep audit (planning/audits/2026-06-14-deep-audit-pass3-findings.md); two prior same-day passes called the relay path clean.

Fix

Extract _maybe_propagate_inbound_headers and strip content-type/correlation_id from the propagated headers only when the result is an OutboxResponse (the path that re-encodes). Foreign-publisher relays (Kafka/etc.) don't re-encode through the outbox envelope, so they keep forwarding these headers verbatim — the existing Kafka content-type-forwarding contract (test_relay.py) is preserved.

The extraction also keeps process_message under the PLR0912 branch limit rather than suppressing it.

Tests

Test-first. Two regression tests in tests/test_fake.py (cross-content-type + custom-correlation_id outbox→outbox relay) — both fail before the fix (relay never delivers), pass after.

• just test → 497 passed, 100% coverage
• just lint clean (ruff + ty)

Docs

• architecture/relay.md — records the envelope-key-stripping invariant.
• Pass-3 findings doc — F5-01/F5-02 marked RESOLVED; F5-03 (no distinguishing signal for non-encode relay-publish failures) noted as the remaining open residual.

🤖 Generated with Claude Code