System.Net.Mail Content-Type param value encoding non-compliant with RFC2047

ContentType encodes all param using RFC 2047 encoding, if it contains any single special or other character. For example:

```
using System.Net.Mail;
using System.Text;

var m = new MailMessage(new MailAddress("alice@abc.com"), new MailAddress("bob@abc.com"));
var a = new Attachment(new MemoryStream(Encoding.UTF8.GetBytes("Hello")), "žížala.txt");
m.Attachments.Add(a);
SmtpClient client = new SmtpClient("127.0.0.1", 49265);
client.Send(m);
```

generates following SMTP communication (markers are from my testing program)

```
<-- 220 fake ESMTP
--> EHLO MREK-DEVBOX-DEV
<-- 250-HELLO
<-- 250 SMTPUTF8
--> MAIL FROM:
<-- 250 OK
--> RCPT TO:
<-- 250 OK
--> DATA
<-- 354 End data with .
<<<====BEGIN====>>>>
MIME-Version: 1.0
From: alice@abc.com
To: bob@abc.com
Date: 7 Sep 2026 16:14:54 +0200
Content-Type: multipart/mixed;
boundary=--boundary_0_ad259f31-3a46-4a9a-9c7e-56e793067c76

----boundary_0_ad259f31-3a46-4a9a-9c7e-56e793067c76
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable

----boundary_0_ad259f31-3a46-4a9a-9c7e-56e793067c76
Content-Type: application/octet-stream;
name="=?utf-8?B?xb7DrcW+YWxhLnR4dA==?="
Content-Transfer-Encoding: base64
Content-Disposition: attachment

SGVsbG8=
----boundary_0_ad259f31-3a46-4a9a-9c7e-56e793067c76--

<<<=====END=====>>>>
<-- 250 OK
```

Improtantly containing

```
Content-Type: application/octet-stream;
name="=?utf-8?B?xb7DrcW+YWxhLnR4dA==?="
```

which violates two RFC 2047 rules from section 5:

```
+ An 'encoded-word' MUST NOT appear within a 'quoted-string'.
```

```
+ An 'encoded-word' MUST NOT be used in parameter of a MIME
Content-Type or Content-Disposition field, or in any structured
field body except within a 'comment' or 'phrase'.
```

Propper way should be implementing encoding as described RFC 2231 rather then 2047. But considering life cycle of System.Net.Mail, we likely want to stay with backward compaible non-compliant behavior I guess?

Reproduce the report with the System.Net.Mail Attachment and SmtpClient example, then trace how ContentType serializes the attachment name parameter. Review the RFC 2047 and RFC 2231 requirements and the compatibility concern before deciding the expected behavior. Done means the project has an agreed encoding behavior and corresponding validation for the generated MIME header.

Written by the indexing model from the issue text.