feat: report the delivered Message-Id from send_email and forward_email - #249

Problem

Composition assigns an RFC 5322 Message-Id to every outgoing message
(emails/classic.py), but no submission result carries it. send_email and
forward_email return only Email sent successfully to <recipients>, so a
caller that keeps its own record of sent mail has to choose between storing an
empty identifier and inventing one. save_to_mailbox already reports the
identifier it appended; sends did not.

Change

Carry the identifier from the SMTP delivery effect through to both tool
responses:

• DeliveryMutationOutcome and SendMutationOutcome gain an optional
  message_id, alongside the existing AppendMutationOutcome.message_id.
• EmailClient.send_email_with_outcome attaches it exactly where it already
  attaches the accepted message — after an accepted DATA phase.
• _complete_send reports it identically on every sent-copy path, so an
  independent Sent-copy failure cannot erase the identifier of a message that
  was demonstrably delivered.
• A clean send appends . Message-Id: <...> to the success line, matching the
  wording save_to_mailbox already uses. A partial delivery reports the same
  value in its own message-id section of the tagged result.

The identifier is never derived from composition. A rejected, timed-out, or
otherwise ambiguous submission reports none, so the response stays honest about
what the server can actually vouch for.

Tests

• Provider: an accepted DATA phase reports the Message-Id that appears in the
  serialized message; a lost DATA result reports none.
• Application: the identifier survives a failed Sent copy for both send and
  forward; a provider timeout and a withheld message report none.
• MCP tools: send and forward name the identifier on success; a partial delivery
  names it in the tagged result; an ambiguous delivery contains no <...@...>
  at all.
• E2E (GreenMail): the identifier reported by send_email and forward_email
  equals the Message-ID the recipient actually received.

Docs and spec

docs/tools.md documents the reported identifier for both tools and its use for
threading a follow-up. spec/07 states the rule normatively and extends
acceptance criterion 6 rather than renumbering the list.

Verification

ruff format --check, ruff check, pyright, pre-commit run -a,
uv lock --locked, dev/build_frontend.py --check, and mkdocs build --strict
are clean. The full suite passes at 83.71% coverage. Four pre-existing failures
on this Windows checkout are unrelated to this change and fail identically on
main (two test_config.py cases assume a C: drive; two require symlink and
owner-assignment privileges). make test-e2e was not run locally — Docker is
unavailable in this environment — so the updated GreenMail assertions rely on CI.

🤖 Generated with Claude Code