MimeUtility.decodeText() incorrectly decodes base64/utf8 atttachment file name divided into two parts with Chinese characters

**Describe the bug**
MimeUtility.decodeText() incorrectly decodes base64/utf8 atttachment file name divided into two parts.
Example:
Content-Type: application/octet-stream;
**name="=?utf-8?B?MV90b18xX2NoYXRfMjE5ODMxMjRfMTkwMzIwMjRf5p2O55SzX+Wwj+ax?=
=?utf-8?B?h+axh0nlj7fmnLouanNvbg==?="**
Content-Transfer-Encoding: base64
Content-Disposition: attachment*/

**To Reproduce**
Steps to reproduce the behavior:
1. Execute: MimeUtility.decodeText("=?utf-8?B?MV90b18xX2NoYXRfMjE5ODMxMjRfMTkwMzIwMjRf5p2O55SzX+Wwj+ax?= =?utf-8?B?h+axh0nlj7fmnLouanNvbg==?=");

**Expected behavior**
Decoded result: "1_to_1_chat_21983124_19032024_李申_小汇汇I号机.json" (according to any mail client)

**Actual Behaviour**
Decoded result: "1_to_1_chat_21983124_19032024_李申_小��汇I号机.json"
(Hieroglyph 汇 decoded as ��)

If to concatinate two parts of encoded name in advance we receive correct value. It seems that MimeUtility should concatinate encoded parts first and only after that to decode them.
MimeUtility.decodeText("=?utf-8?B?MV90b18xX2NoYXRfMjE5ODMxMjRfMTkwMzIwMjRf5p2O55SzX+Wwj+axh+axh0nlj7fmnLouanNvbg==?=");

jakarta.mail-api:2.1.3

Start at the MimeUtility.decodeText() entry point and reproduce the supplied two-part encoded filename case. Compare its result with the expected filename, ensuring the split UTF-8 Base64 sections are handled without replacing the Chinese character; verify the corrected behavior using the reproduction input.

Written by the indexing model from the issue text.