fix: append a copy of every sent message to the sent folder

[TRC-Loop]

Fixes #451.

Sent mail was delivered and no copy was ever kept. Not on the server, not locally. The report traced it exactly right: the append step is wired through psmtp.WithSentAppender, and the one place that builds the sender never passed it, so appendSent was nil on every send and the step returned immediately. Transmit then returned nil, the outbox marked the message sent, and the compose window said it had worked.

The only trace was a Debug line, and file logging is off by default, so a total loss of sent copies looked exactly like normal operation.

Confirmed before changing anything: WithSentAppender had one caller in the whole repository, cmd/smtptest, a debug tool. Nothing in internal/desktop ever called it.

The fix

accountTransmitter.Transmit now passes an appender that opens an imap session for the account and calls AppendToSent, which internal/imap/append.go already implemented correctly, special-use \\Sent lookup and name fallbacks included. It was simply never reached.

AppendToSent joins the mailClient seam, which is why it was awkward to wire before: there was no way to get a client for an account through the interface the bindings use, and going around it would have put the send path outside the seam every other binding is tested through.

Three decisions worth stating:

• Its own session, not the sync engine's. That one sits in IDLE nearly all the time, and interrupting it to append would cost more than a second connection does for something that happens once per sent message.
• It takes syncMu. Every other imap session in the package does, so a send during a sync waits its turn instead of opening a competing login.
• Appended to the server, not written locally. The next sync pulls it down like any other message, so there is one path for how mail enters the store.

Tests

Two, driving the real transmit path against an in-process submission server, with the account pinning the server's certificate through the trust added in #453.

Testing the helper alone would have been worthless here: the helper was fine, the wiring was missing, and a helper test would have passed for the entire time the feature was dead. So the assertion is on Transmit as the outbox worker calls it. I checked it fails for the right reason by reverting the one-line wiring: appended 0 messages to Sent, want 1.

The second test covers the case where the append fails: the message has already been delivered, so reporting failure would have the outbox retry and send it twice. It stays a warning.

Not done here

The report also asks for a visible signal when the copy cannot be written. It is a Warn today and nothing surfaces in the interface. That is a real gap and worth its own issue, but it is a question about how to show it rather than part of this fix.