engine: Ctrl+H reaches back into the text the client already has

Korean commits a syllable as the next one begins, so by the time the
한자 key is pressed only the last syllable is still ours: typing 한자 and
then Ctrl+H asked about 자 alone and answered 子, leaving 한子 in the
document -- the mixed Hangul and Hanja that was refused as dictionary
data, made by the interaction instead.  To get 漢字 the key had to be
pressed before typing, which no other Korean input method asks for.

A request now carries the client's own text just before the cursor, and
the reading reaches back through it as far as the dictionary still knows
the whole of it: 한 joins 자 and 대한민 joins 국.  Nothing but the
dictionary says where to stop, because a reading is syllables, so a key
holding a space or an already converted Hanja leads nowhere and the
reach ends there.  A pick answers with the count of runes to take back
first; Escape gives back only what was pending, and a query with no
candidate types only the part the client lacks.

A frontend that sends no surrounding text reaches back by nothing and
behaves exactly as before, which is what XIM will keep doing.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

tests/test.h

@@ -86,6 +86,7 @@ void	engine_emoji_preedit_languages(struct ct*);
 void	engine_emoji_start_and_unknown(struct ct*);
 void	engine_hanja_search(struct ct*);
 void	engine_hanja_unknown_and_cancel(struct ct*);
+void	engine_hanja_reaches_back(struct ct*);
 void	engine_hanja_word_prefix(struct ct*);
 void	engine_hanja_korean_keys(struct ct*);
 void	engine_hanja_backspace(struct ct*);