fix: guard QuotedPrintable decode against truncated =XY escapes

[guettlibot]

Problem

QuotedPrintableMailCodec.decodeText at lib/src/codecs/quoted_printable_mail_codec.dart:199 calls cleaned.substring(i + 1, i + 3) unconditionally whenever it encounters =. Two independent inputs make i + 3 exceed cleaned.length and throw a RangeError:

1. Outer branch, truncated tail. Input ending in a bare = or =X (e.g. "hello=", "hello=A", "h=A").
2. Inner while loop, off-by-one guard. The guard cleaned.length > (i + 4) && cleaned[i + 3] == '=' proves cleaned[i + 3] exists, but after the following i += 3 the substring reads cleaned[i+4..i+5], so a valid multi-byte escape followed by a truncated tail like "hi=C3=B6=A" still throws.

Minimal repro against 2.1.7 / current main:

MailCodec.quotedPrintable.decodeText('hello=', convert.utf8);
// throws: RangeError (end): Only valid value is 6: 8

Fix

RFC 2045 §6.7 permits consumers to preserve malformed quoted-printable input verbatim, and the existing int.tryParse == null branch already does that for non-hex =XY. This PR extends that policy to the two truncated cases:

• Before the outer substring, check i + 3 > cleaned.length; if so, append the malformed tail (cleaned.substring(i)) to the buffer and break.
• Inside the inner while loop, add if (i + 6 > cleaned.length) break; so a truncated inner escape falls through to the outer truncated-tail branch on the next outer iteration.

No behaviour change for well-formed input; the full existing test suite passes (dart test, 420 tests).

Tests

Added a regression group malformed truncated =XY escapes are preserved verbatim in test/codecs/quoted_printable_mail_codec_test.dart covering:

• trailing bare =
• trailing =A
• lone =A at end of a short input
• valid multi-byte escape followed by truncated =A (exercises the inner-loop path)

Each asserts the decoder returns the input verbatim rather than throwing.

Downstream context

Reported from downstream in guettli/sharedinbox#232, where an incoming mail body whose quoted-printable payload ended mid-escape crashed the entire Flutter app via runZonedGuarded → FlutterError.onError → CrashScreen. That project has since added a defensive try/catch at the call site, but the foreground getEmailBody path for the currently viewed email still hits the same crash on any similar malformed message. This upstream fix protects all callers.

Non-goals

• Not fixing the int.parse inside the inner while loop (which can still throw FormatException on non-hex input there). That is a distinct latent bug from BUG: in serialization of ServerConfig.fromJson() #232 and is left for a focused follow-up.
• Not touching the print(...) diagnostics.