Fix decoding of multi-segment RFC2231 extended attachment filenames - #10268

Problem

An attachment whose filename is split across multiple RFC2231 extended (percent-encoded) parameters is decoded only in its first segment; the continuation segments remain percent-encoded, producing a corrupted filename.

Example header:

Content-Disposition: attachment;
 filename*0*=UTF-8''%e2%82%ac;
 filename*1*=%e2%82%ac

was decoded to €%e2%82%ac instead of €€.

Root cause

rcube_mime_decode::parseHeaderValue() (program/lib/Roundcube/rcube_mime_decode.php:295-307) applied rawurldecode() only when a segment carried the charset'lang' prefix (matched at line 299), which is present only on the first segment (filename*0*). Continuation segments (filename*1*, filename*2*, …) have no such prefix and fell through with their value appended raw, still percent-encoded.

Fix

The parameter regex now captures the trailing * that marks an extended (percent-encoded) parameter. Continuation segments of an extended parameter are rawurldecode()'d before concatenation. Plain (non-extended) continuations (filename*0=, no trailing star) are still treated as literal and are not decoded, per RFC2231.

Testing

Added tests/Framework/MimeDecodeTest.php cases:

• test_decode_rfc2231_extended_continuation: multi-segment filename*0*/filename*1* assembles to the fully decoded value (fails before the fix, passes after).
• test_decode_rfc2231_plain_continuation: plain filename*0/filename*1 continuation stays literal (%20 not decoded).

Full MimeDecodeTest passes (3 tests, 14 assertions); phpstan level 4 on the changed file reports no errors.