Fix Sender.Email leaking mailbox-owner address when authoritative sender properties are absent

[tariqgitspace]

Problem

When a .msg file is saved from a recipient's mailbox (rather than the original sender's Sent Items), the authoritative MAPI sender properties

• PR_SENDER_EMAIL_ADDRESS (0x0C1F)
• PR_SENDER_SMTP_ADDRESS (0x5D01)

are often absent. SetEmailSenderAndRepresentingSender then falls through to non-authoritative sources:

• PR_SENDER_SMTP_ADDRESS_ALTERNATE (0x6512)
• InternetAccountName
• PR_PRIMARY_SEND_ACCT (0x0E28)

On items saved by Outlook from a recipient's mailbox, those fields are often populated with the mailbox owner's own SMTP address rather than the real sender's. The observable result is:

• Sender.DisplayName is correct (from PR_SENDER_NAME) — shows the real sender's name.
• Sender.Email is wrong — it contains the mailbox owner's SMTP address, i.e. one of the message's recipients.

This is misleading and causes downstream consumers to attribute the message to the wrong party.

Fix

1. Track whether the resolved sender email came from an authoritative property (PR_SENDER_EMAIL_ADDRESS or PR_SENDER_SMTP_ADDRESS) via a new local flag senderEmailIsAuthoritative.

2. Just before constructing the Sender object, if the email is not authoritative and matches the SMTP address of any entry in _recipients (OrdinalIgnoreCase), clear it. DisplayName is preserved, so consumers still see the real sender's name; only the misleading mailbox-owner address is suppressed.

Why this is safe

The guard is intentionally narrow — it only fires when both:

• the fallback path was used (no authoritative sender property was present), and
• the resolved address actually collides with a known recipient on the message.

Messages with correctly-populated PR_SENDER_EMAIL_ADDRESS / PR_SENDER_SMTP_ADDRESS are completely unaffected, as are fallback-resolved addresses that don't collide with any recipient.

Scope

• Single file changed: MsgReader/Outlook/Message.cs
• No public API change.
• Logger.WriteToLog emits one line when the guard fires, to aid diagnosis.
• No unit test added — hand-crafting a synthetic CFB .msg to exercise this property combination is non-trivial; happy to add one if a recommended approach exists in the repo.