Romaji to Kana Converter: Angular & Express — Chapter 2, Exercise 2
=====================================================================

TASK
Build convertNaiveV1 (the fixed 2-then-1-character tokenizer) exactly
as this chapter describes. Run it against "kyaku" and confirm the
real "kやく" output, then run it against "kaki" (a word with no
3-character exception tokens at all) and confirm it works correctly
there -- showing the bug specifically depends on a 3-character token
being present, not a universal failure. (Note: "sushi" is not a safe
comparison word for this, since "shi" is itself one of the real
3-character exception tokens and would also break.)

SOLUTION

  function convertNaiveV1(romaji: string): string {
    let hiragana = '';
    let i = 0;
    while (i < romaji.length) {
      const two = romaji.slice(i, i + 2);
      const one = romaji.slice(i, i + 1);
      if (KANA_MAP[two]) {
        hiragana += KANA_MAP[two].hiragana;
        i += 2;
      } else if (KANA_MAP[one]) {
        hiragana += KANA_MAP[one].hiragana;
        i += 1;
      } else {
        hiragana += romaji[i];
        i += 1;
      }
    }
    return hiragana;
  }

Testing:

  console.log(convertNaiveV1('kyaku'));
  console.log(convertNaiveV1('kaki'));

Run with: node (or ts-node)
Output (verified by hand-running the real function):

  kやく
  かき

kyaku fails exactly as the chapter describes: "ky" isn't a valid
2-character token, "k" isn't a valid 1-character token either, so the
raw letter k is emitted unconverted, before "ya" (や) and "ku" (く) are
each picked up correctly as ordinary 2-character tokens on their own.

kaki (a real word — either 柿, persimmon, or 牡蠣, oyster) succeeds
completely: ka is a genuine, regular 2-character token (か), and ki is
too (き), so the naive tokenizer never needs a 3-character check at
all here. That's exactly why "sushi" would have been a misleading
choice for this comparison -- it contains "shi," which is itself one
of the real 3-character exception tokens (an irregular Hepburn
spelling, not a regular 2-character K/S/T/N/etc.-row entry), so it
would fail under convertNaiveV1 for the identical underlying reason
"kyaku" does, not demonstrate the naive version working correctly.

WHY THIS WORKS AS AN ANSWER
----------------------------
It reproduces the real "kやく" bug from the chapter, then verifies a
genuinely clean counter-example ("kaki") that contains no 3-character
tokens of any kind -- confirming the naive tokenizer's failure really
is scoped to inputs containing a 3-character token, and explicitly
explains why "sushi" would have been the wrong word to use for that
comparison, since it happens to contain a different real 3-character
exception ("shi") that would have broken it too.