Sync SPEC.md from fmsg-spec v0.5.0 consistency fixes

[markmnl]

Syncs SPEC.md with markmnl/fmsg#29 (spec v0.5.0 consistency fixes). The spec changes largely encode what fmsgd already does, so no code changes are needed here: stored-message verification includes messages the host sent, exactly one header-response code, add to may not overlap to, add-to copies omit topic and set has-pid, an unsupported message version gets code 2 (an unsupported CHALLENGE version terminates without responding — see #40).

Also encodes the confirmed add-to design ruling: added recipients are participants of the add-to batch message only (their replies reference the batch via pid); batches form sibling branches under the original, so the thread evolves as a tree; and batch identity is the batch message hash (which covers time) — re-issuing the same addresses at a new time is a distinct batch, not a duplicate.

Confirmed follow-up fixes (to land as separate small PRs, this PR stays docs-only)

• addToBatchRecorded identifies a duplicate batch by recipient-address set (msg_add_to rows), whereas SPEC §11 defines batch identity by message hash (which includes time) — a re-issued batch with the same addresses but a new time must be recorded as a distinct batch, not rejected as a duplicate.
• After code 64/65, download/storage errors write a single global code 3 into what the sender reads as the per-recipient code stream (host.go ~1751-1759, ~1450-1457, ~1552) — spec calls for per-recipient 105 (or aborting); the sender ends up recording code 3 as a recipient's code.
• storeMsgHeaderOnly's INSERT branch (store.go:576) is unreachable (code 11 is only issued when the parent row exists, so the attach path always wins); if it were ever reached, the reloaded row would have Pid equal to its own hash and isMessageRetrievable would recurse on itself. Remove the branch.
• Cosmetic: Flags&FlagHasPid == 1 (pkg/fmsg/fmsg.go:93, host.go:1014) works only because the flag is bit 0; use != 0.

Resolved by design ruling (not bugs)

• Earlier-batch participants are never notified of later batches — by design: participants added in an earlier batch are not participants of a later batch message, so they are not notified of it.
• Locally-delivered-only messages never get a sha256 — not a bug: every legitimate remote reference to such a message arrives via an add-to batch, which crossed the wire and has its hash. Optional hygiene: compute the hash at store time for uniformity.

🤖 Generated with Claude Code