Add integration test 013: multi-recipient and multi-domain fan-out

[markmnl]

Every other test sends to exactly one recipient, leaving two things unexercised (SPEC §10.2, §10.2 step 6, §10.4 step 6).

1. The per-recipient response byte stream. When two recipients share a domain, the sending host opens one connection and reads one byte per recipient, matched positionally to _to_ order. With a single recipient, a misaligned stream is indistinguishable from a correct one. So cases A1/A2 pair the unseeded @dave@example.com (rejected 100, per test 012) with @bob@example.com (accepted 200) and send them in both orders:

	_to_ order	expected codes
A1	[dave, bob]	[100, 200]
A2	[bob, dave]	[200, 100]

Identical codes would prove nothing. Differing codes in both orders catch both a one-byte misalignment and an implementation that matches codes to addresses rather than to positions — with a single ordering, either bug still passes.

2. Fan-out across unique recipient domains, where responsibility is split. Case B addresses one message to hairpin.local and example.com at once: alice's outcome is recorded by fmsgd off the wire, carol's by fmsg-webapi's resolveLocalDelivery — fmsgd's sender deliberately skips the local domain, so nothing else would ever set it.

Both cases additionally assert something SPEC §11 makes a MUST and no test covered: a receiving host retains the complete _to_ list, including recipients on other domains and ones it rejected, so participant checks and hash recomputation stay faithful.

Notes

• The ordering assertion was verified to be able to fail: swapping A1's expected codes makes the test fail (expected code 200 for @dave@example.com, got '100'), and it passes again when restored. A test that passes on the first run is worth proving isn't vacuous.
• fmsg-cli has no multi-recipient send, so these go out as drafts whose recipient list is replaced via update --to. The body is passed again on that call deliberately: despite the CLI's "only provided fields are updated", PUT /fmsg/:id rewrites the whole message from the payload, so a bodyless update would leave an empty body. That mismatch looks like a genuine bug in the CLI/webapi contract — worth its own issue rather than a fix smuggled into a test PR.
• tests-to-add.md: 013 crossed off, and 014 narrowed — it now covers only the untested remainder (a message with only local recipients, which never reaches fmsgd's outbound sender).

Full suite locally: 13 passed, 0 failed.

🤖 Generated with Claude Code