Romaji to Kana Converter: Astro — Chapter 3, Exercise 3
=====================================================================

TASK
Build convertSentence with the particle overrides, then run it
against both "kore e ikimasu" and "kono e wa kirei desu". Confirm the
first is correct and the second is wrong (produces へ where え would
be correct), and write one sentence explaining why no purely
lookup-table-based fix could resolve this specific ambiguity.

SOLUTION

Running convertSentence against both real sentences:

  console.log(convertSentence('kore e ikimasu').hiragana);
  // 'これ へ いきます' -- correct: "e" here really is the へ direction
  // particle, "I'm going this way"

  console.log(convertSentence('kono e wa kirei desu').hiragana);
  // 'この へ は きれい です' -- "wa" correctly resolves to は, but "e"
  // incorrectly becomes へ where the correct character is actually
  // え, since this sentence means "This picture is pretty" (e = 絵)

Both outputs confirmed against real function execution. The second
sentence demonstrates the real, documented limitation directly: the
converter applied the exact same word-boundary rule to a standalone
"e" in both sentences, and got one right and one wrong, because the
two sentences are structurally identical at the level this converter
actually looks at -- a lone word "e" sitting between other words -- and
only differ in real-world meaning, which a lookup table has no access
to at all.

The one-sentence reason no purely lookup-table-based fix can resolve
this: a lookup table can only ever look at the isolated word "e" in
front of it, but deciding whether that "e" means the へ particle or
the noun 絵 genuinely requires understanding the sentence's actual
grammatical role and meaning -- real part-of-speech and semantic
context that a word-by-word substitution table structurally has no
way to represent, no matter how the table itself is built or extended.

WHY THIS WORKS AS AN ANSWER
----------------------------
It verifies both real outputs rather than assuming the theoretical
description is accurate, and the explanation names the real root
cause -- a lookup table operates on isolated words with no
grammatical context, and this specific ambiguity can only be resolved
with information a lookup table never has access to -- rather than
suggesting a more elaborate table could eventually patch it.