fix: Honor ContentType parameter for FilePath-based linked resources

[Copilot]

When calling AddLinkedResource(string filePath, string contentType, string contentId, string? fileName = null), the contentType parameter was stored but ignored during MIME message construction, causing linked resources to always use auto-detected content types.

Changes

• MailClient.cs: FilePath-based linked resources now read file as bytes and pass explicit contentType to bodyBuilder.LinkedResources.Add(), matching the pattern used by FileUrl and FileBytes handlers
• Falls back to MimeKit.MimeTypes.GetMimeType() when contentType is null

Example

// Content type is now properly applied instead of being ignored
context.Attachments.AddLinkedResource(
    "path/to/image.bin",  
    "image/png",           // This now takes effect
    "logo"
);

Previously, the image would be added with MIME type detected from .bin extension. Now it correctly uses image/png.

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[Copilot]

Pull request overview

This PR fixes a bug where the contentType parameter was ignored when adding FilePath-based linked resources, causing them to always use auto-detected content types instead of the explicitly specified type.

Key Changes:

• Modified FilePath-based linked resource handling to read file bytes and pass explicit content type to MimeKit
• Aligned implementation with existing FileUrl and FileBytes handler patterns

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.