Fix backspace to delete composing chars in Khipro layout

[qomarhsn]

Previously, pressing backspace while composing Bengali text with the Khipro layout would incorrectly commit the entire word to the text field instead of deleting characters one-by-one. This fix adds proper DELETE key handling to BnKhiproCombiner that removes characters from the composing buffer (preedit), and when the last character is deleted, cleanly commits the word by returning a SPACE event. Additionally, a safety check in WordComposer synchronizes the cursor position when the word becomes empty, preventing a crash caused by the cursor position being out of sync with the code point size.

[qomarhsn]

Known issue

There is a small known issue in some apps (not all), mainly AI chat apps like ChatGPT, Perplexity, Grok, and Qwen.

After typing ami tfaip korchi → আমি টাইপ করছি, deleting করছি character by character works correctly. The text then becomes আমি টাইপ (with a trailing space).

Before deleting that space, if I start typing a new character or press space, the IME sometimes commits the last part of the previously deleted word e.g. ক and then continues with the new input.

[qomarhsn]

Known issue

There is a small known issue in some apps (not all), mainly AI chat apps like ChatGPT, Perplexity, Grok, and Qwen.

After typing ami tfaip korchi → আমি টাইপ করছি, deleting করছি character by character works correctly. The text then becomes আমি টাইপ (with a trailing space).

Before deleting that space, if I start typing a new character or press space, the IME sometimes commits the last part of the previously deleted word e.g. ক and then continues with the new input.

I noticed the same behavior also happens in the Korean phonetic layout. So it seems this might not be specific to the BnKhiproCombiner, but related to the main combiner system.

@Helium314 could you please check if this is coming from the main combiner system? If so, this PR should be safe to merge.

[Helium314]

This behavior occurs for me in HeliBoard settings (search field), so I assume it's a problem with compose.
If you have e.g. " ㅂㄱ " in the text field and start deleting characters, once you delete ㅂ the text cache is reloaded (because the app detects an inconsistent state), but actually the wrong state is loaded, because when you ask via the InputConnection the ㅂ is still there.
A few ms later we get a selection update (onUpdateSelection) from the text field, which is seen as a "real" (not expected) update because the expected and actual selections mismatch. Now the text is reloaded again from the text field, and in that example we have newSelStart 1 (i.e. cursor position 1), but when we ask the InputConnection AFTERWARDS what is before the cursor, we get " ㅂ", i.e. 2 characters.

I don't think there is anything we can do against such behavior. When we only trust our cache, then we will not read text field changes intended by the app. When we trust the text field, then we can only lose because the text field says the cursor is after the first character, but there are 2 characters before the cursor.

What a waste of 3 hours... if only text field devs would give a shit about the "Editor authors:" part in documentation