Romaji to Kana Converter: Astro — Chapter 4, Exercise 1
=====================================================================

TASK
Build index.astro exactly as this chapter describes, run npm run dev,
and type "kya" into the input box one letter at a time. Confirm you
see the same live intermediate output this chapter verified (k, then
ky, then きゃ) before writing down what you observed.

SOLUTION

With the page and script wired up exactly as shown in the chapter,
typing into the real input box in a browser and watching the
hiragana-output element after each keystroke shows:

  After typing "k":   the output area shows "k"
  After typing "ky":  the output area shows "ky"
  After typing "kya": the output area shows "きゃ"

This matches the chapter's own verified sequence exactly. The
mechanism is the same one Chapter 2 built for any unrecognized input:
at "k" and "ky", the longest-to-shortest tokenizer never finds a
match at position 0 (neither "k" nor "ky" is a valid token, and only
vowels and n are valid one-character tokens), so both raw letters are
emitted unconverted, one at a time as they're typed. The instant a
third character makes "kya" a genuine match, the very next call to
convert() -- triggered by that same keystroke's input event -- finds
the full 3-character token immediately and returns きゃ, replacing
the entire previous "ky" in one visible update.

Nothing about this required any special handling in the script itself
-- the same convert() function that was already fully built and
tested in Chapter 2 behaves correctly here with zero changes, simply
because it's now being called once per keystroke on a growing string
rather than once on a finished one.

WHY THIS WORKS AS AN ANSWER
----------------------------
It confirms the real observed browser behavior matches the chapter's
own verified sequence exactly, and explains why no new logic was
needed to produce it -- the same longest-to-shortest matching rule
from Chapter 2 already accounts for every intermediate state a
growing input string can be in.