fix(osc): decode OSC payloads to UTF-16 instead of aborting on bad bytes

[GlassOnTin]

invokeOscSequence hands the raw OSC payload to NewStringUTF. That call doesn't fail politely — ART treats invalid modified UTF-8 as fatal and aborts the process. There's no exception to catch and nothing the Kotlin side can do about it; the app is just gone.

An OSC payload is whatever the remote program chose to emit. A window title from a non-UTF-8 Windows console has no obligation to be valid UTF-8, so this is reachable from any hostile — or merely mis-encoded — remote host.

This decodes to UTF-16 and uses NewString, which has no such failure mode. Malformed sequences become U+FFFD. A terminal that shows a replacement character for a mis-encoded title is behaving correctly; one that kills the app is not.

Why not route through utf8_to_mutf8

That was my first instinct, and it doesn't work — for two reasons that are worth flagging on their own:

1. It assumes well-formed input. A lone continuation byte falls through to the "1, 2, or 3 byte sequence" branch and is copied verbatim, so the output is still invalid and NewStringUTF would still abort.

2. Its 4-byte branch reads out of bounds. (c & 0xF8) == 0xF0 leads to reading p[1], p[2], p[3] with no check that those bytes are within the buffer. A truncated 4-byte sequence at the end of the input reads past the end. Pass 1 has the same shape (p += 4 unchecked).

I have not touched utf8_to_mutf8 in this PR — the new decoder doesn't use it, and I didn't want to bundle an unrelated change into a bug fix. But (2) is a live out-of-bounds read in the tree regardless of this PR, and I'm happy to send a separate one for it if you'd like. It's reachable from setTermProp with a string property whose last character is a truncated 4-byte sequence.

The new decoder length-checks every sequence before touching a continuation byte, and rejects overlong encodings and encoded surrogates.

Also sized from the std::string rather than c_str(), so a payload containing an embedded NUL is passed through whole instead of silently truncated at the NUL.

What the tests prove, and what they don't

Worth being explicit, because the green tick is misleading on its own:

The tests run on the host JVM, whose NewStringUTF is lenient — it returns mojibake rather than aborting. Only ART aborts. I measured this: with the fix reverted, the three "does it survive" tests still pass. They cannot catch the abort and are not evidence against it. I've said so in the test file rather than leave a passing test implying coverage that isn't there.

malformedBytesBecomeReplacementCharacters is the one that genuinely fails without the fix. It drives an OSC 1337 annotation — which reaches this exact code path and stores its payload as readable segment metadata — and asserts the bad byte arrives as U+FFFD with the valid text either side intact. Confirmed failing against the unfixed tree, passing with the fix.

Full suite: 374 tests, 0 failures.

Found while investigating a native SIGABRT report downstream. It is explicitly not that crash — in the reported trace every OSC call completed, and the log line is emitted before the string is created, so an abort here would have left a call with no matching return. Sending this on its own merits.

[GlassOnTin]

Added a second commit to this PR: invokeOscSequence no longer logs the payload at all.

It's the same function and the same argument about untrusted remote data, so it seemed to belong here rather than in a separate PR — happy to split it out if you'd rather review them independently.

The reason it matters more than a typical log tidy-up: OSC 52 is the clipboard. termSelectionSet passes the decoded copied text through this exact call, so anything copied in a remote session — a password out of a manager, an API token, a private key — was written to logcat in plaintext. OSC 3008 carries user, hostname and cwd for the same ride.

Not silent harvesting: another app can't read the log on Android 4.1+. The exposure is sharing — adb logcat and adb bugreport capture it, and any app that surfaces its own logs, or asks users to attach one to a bug report, carries it straight out. This surfaced downstream when someone had to hand-redact their own log before it was safe to attach to an issue.

Command number and length are kept, since that's what makes the line useful for sequencing and truncation bugs and neither reveals content.

Both commits verified together: 374 tests, 0 failures, and spotlessKotlinCheck clean this time.