fix: send from the address a message was delivered to (shared/aliased mailboxes)

[rotterp]

On a shared, group or aliased mailbox every reply, reply-all, forward and new
message went out as identities[0] — the account owner — no matter which
mailbox was open. Users hit this as "it keeps sending as the wrong address and
I have to fix the From by hand every time".

The cause

Two different behaviours were fused behind autoSelectReplyIdentity, which
ships off:

1. Own-identity match — pick among the user's configured identities
   (exact address, then +tag-stripped). Never rewrites From:; it only
   chooses which of your own addresses sends. This is the Thunderbird/Outlook
   default.
2. Domain catch-all rewrite — put an address you have not configured into
   From:, sending through a same-domain identity ([Feature]: Make the from-address field editable #246).

(1) is what makes a shared mailbox reply from its own address. It carries no
impersonation risk, so this makes it unconditional. findReplyIdentityId
already implemented exactly this and was, until now, referenced only from tests.

(2) stays behind the setting, whose description already promises precisely that
behaviour. It has to stay opt-in: ownedDomains treats any address on a
domain you hold an identity on as a catch-all candidate — including a
colleague's, and including one seen only in Bcc: — so on a multi-user domain
it can put someone else's address in your From. Enabling it for everyone would
have been a regression, not a fix.

What else this fixes

• forward was excluded from the resolution entirely, so forwarding a
  message that arrived at a shared mailbox went out as the owner — even though
  the comment above the gate already promised "Reply/forward fall through to
  the recipient-based resolution below", and the neighbouring inline-image
  effect in the same file groups all three modes together. Forwards take (1)
  but deliberately never (2): a reply continues a thread whose participants
  know the addressing, while a forward introduces a rewritten From to a
  recipient the user just typed, who cannot tell it isn't genuine.
• handleQuickReply is narrowed to (1). That surface is a bare text box
  with no From row, so a rewritten From would be applied with nothing on screen
  to show it — or correct it.
• ProComposeTabBody never passed composeFromAccountEmail, so in the
  Pro/embedded shell mode === 'compose' resolved to null and every new
  message defaulted to the account owner. That covered the whole compose
  surface there, since the Pro shell hoists every "show composer" intent —
  mailto: links included — into a tab.
• handleStateChange gated the email-list refresh on the primary account.
  Stalwart's SSE never pushes StateChange for a delegated/shared owner, so
  those changes arrive only via the secondary poll under the owner's
  accountId. With a shared folder open, a background change refreshed the
  folder counters (anyMailboxChanged already reacts to every account) but
  never refetched the rows — so a server-side keyword patch, or another member
  of the shared mailbox acting on it, stayed invisible until a hard reload.
  Uses the existing resolveViewAccountId() helper.

Scope and limits

The refresh covers the first page of the open list, which is what
refreshCurrentMailbox fetches; rows scrolled past it are still re-appended
from local state. It is not instant either — the shared-account poll runs on
the secondary (20s) interval and is skipped while the tab is hidden.

Testing

16 tests across the two suites. Each fix was verified by reverting it and
confirming the intended cases go red while the controls stay green:

• restoring the old identity gate → exactly 3 red (reply, forward, self-sent)
• restoring the primary-only refresh gate → exactly 2 red (owner, aggregate)

Controls included on purpose: the catch-all rewrite still fires on a reply
when the setting is on, so the "no rewrite" tests prove the gate rather than a
broken resolver; and Mailbox-only changes, unrelated accounts and own-account
views must not trigger a refetch.

Note the composer suite's settings mock hard-coded autoSelectReplyIdentity: true while the shipped default is false — so the shipped configuration was
the one nothing exercised. The mock now matches the default.

tsc --noEmit and eslint are clean. 652 tests pass across the affected
suites; the 3 auth-store-logout failures are pre-existing on main.