fix(input): correct the accelerated backspace emoji measurement

[AsafMah]

Fixes #133

What this is now

This PR was originally a paragraph-backspace fix. Device testing did not confirm the bug, so the unverified behaviour change has been split out to the parked draft #140, and what remains here is only what's independently correct.

What device testing showed

On the reporter's Samsung SM-S936B, driving the real on-screen backspace key against the unfixed build:

App	Flow	Result on unfixed build
Samsung Notes	type → Enter → backspace	merged correctly
Samsung Notes	caret moved in by tap, then backspace	merged correctly
MS Word	type → Enter → backspace	merged correctly
MS Word	caret to paragraph start via MOVE_HOME	merged correctly
MS Word	empty paragraphs (Enter ×3)	removed correctly
MS Word	held backspace across the boundary	deleted through correctly

Both apps honour deleteSurroundingText across a paragraph boundary, contradicting the premise. The reporter's settings are all defaults (gesture_method=fallback), so no exotic fork backspace path was armed either. See #140 for the full write-up and what would un-park it.

What's left here

A real bug, independently verifiable. The accelerated (held-backspace) second deletion measured its length from codePointBeforeCursor — the code point read before the first deletion — instead of codePointBeforeCursorToDeleteAgain:

final int codePointBeforeCursorToDeleteAgain = mConnection.getCodePointBeforeCursor();
if (codePointBeforeCursorToDeleteAgain != Constants.NOT_A_CODE) {
    final int lengthToDeleteAgain = codePointBeforeCursor > 0xFE00        // <-- wrong variable
            || StringUtils.mightBeEmoji(codePointBeforeCursor)            // <-- wrong variable

When the second character back is a multi-code-point emoji this picks length 1 and splits it; in the opposite case it over-deletes. Only reachable once mDeleteCount > DELETE_ACCELERATE_AT, i.e. while holding backspace, which is probably why it went unnoticed. Present in upstream v4.1.2 too — reported as LeanBitLab/LeanType#423.

Two latent test-harness bugs.

• deleteSurroundingText didn't clamp to the available text and drove selectionStart negative on an empty field.
• setText accepted a requireIdle parameter and then called handleMessages() without it, so reset() couldn't tolerate a leftover delayed message. Harmless until adding tests reshuffled JUnit's hash-based method ordering, at which point it failed an unrelated test during setup rather than in its own logic.

Test infrastructure kept. The fake InputConnection can simulate a block-based editor: paragraph-scoped reads, and cross-paragraph deletes that report success while doing nothing (deliberately mirroring the "returns true but no-ops" behaviour that makes this class of bug invisible). The two tests asserting the parked behaviour are @Ignored with the device findings recorded inline, so the hypothesis and the evidence against it stay together rather than the hypothesis quietly disappearing.

Verification

324 tests, 4 failed — the documented Windows-only ParserTest baseline, confirmed with tools/check_test_results.py from #139 (which also checks the results aren't stale and that its own enumeration agrees with the declared totals).