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

TASK
Find a real word (not "na" and not "konnichiwa") that triggers
convertNaiveV2's own ascending-order bug, verify it with real code,
and explain why it triggers the bug.

SOLUTION

"kani" (蟹, crab) is a clean, real example:

  > convertNaiveV2('kani')
  { hira: 'かんい', kata: 'カンイ' }   // should be かに

The intended tokenization is ka + ni: "ka" matches as a real
2-character key, giving か, then the remaining "ni" should match as
its own real 2-character key, giving に. Instead, convertNaiveV2
tries length 1 first at every position. Once か is correctly
matched and consumed, the pointer sits at "n," and length 1 is
checked before length 2 -- "n" alone IS a valid standalone key (the
syllabic n token), so it matches immediately as ん, consuming only
that one character. The pointer then sits at "i" alone, which
matches as its own 1-character key い. The real 2-character token
"ni" is never even attempted, because the shorter "n" match already
succeeded and consumed the "n" before "ni" could be checked as a
whole chunk.

This is the exact same root cause the chapter's own "na" and
"konnichiwa" examples demonstrate: any romaji word containing "n"
immediately followed by a vowel that would normally combine into a
real 2-character na/ni/nu/ne/no token is vulnerable, because the
ascending-length search always finds and accepts the standalone "n"
match first. "kani" shows the bug can appear in the middle of an
otherwise simple two-syllable word, not just at the very start the
way "na" does.

WHY THIS WORKS AS AN ANSWER
----------------------------
It finds and verifies a genuinely new example with real, executed
code rather than reusing one already shown in the chapter, and
explains it by tracing the identical root cause (the standalone "n"
token always winning under ascending-length search) rather than
treating it as an unrelated new bug.