Romaji to Kana Converter: React & Next.js — Chapter 5, Exercise 1
=====================================================================

TASK
Simulate real, live typing of "sushi" one character at a time against
convert(), exactly as this chapter did for "kyoto." Predict the output
at each step first, then verify with real code.

SOLUTION

Running the real tokenizer against "sushi," typed one character at a
time:

  typed "s"      => {"hiragana":"s","katakana":"s"}
  typed "su"     => {"hiragana":"す","katakana":"ス"}
  typed "sus"    => {"hiragana":"すs","katakana":"スs"}
  typed "sush"   => {"hiragana":"すsh","katakana":"スsh"}
  typed "sushi"  => {"hiragana":"すし","katakana":"スシ"}

The interesting difference from "kyoto" shows up at step 2. "kyoto"
needed three whole characters ("kyo") typed before its own first
token snapped in, because きょ is a yōon combination stored under the
3-character key "kyo." "su," by contrast, is a real, complete 2-
character gojūon token on its own -- KANA_MAP["su"] exists directly
-- so it converts to す/ス the instant the second character is typed,
one character sooner than "kyo" needed.

From there the pattern matches "kyoto" exactly: the trailing raw "sh"
() sits untouched as plain Latin text because "sh" alone isn't a
real key in KANA_MAP, until the fourth character completes "shi" (a
real 3-character token) and it snaps to し/シ in one keystroke, exactly
the same way "kyot" -> "kyoto" resolved きょt -> きょと.

WHY THIS WORKS AS AN ANSWER
----------------------------
It runs the real tokenizer against a fresh word rather than reasoning
about it in the abstract, and correctly identifies the real reason
"su" resolves one character sooner than "kyo" did -- "su" is itself a
complete 2-character token, where "kyo" needs all three characters of
its own 3-character yōon key before anything matches.