Phase 21: Petal learns to be an English+Portuguese pair

The plan said "Hunspell pt-PT vendored like en-US". Measuring that first is
what saved it: nspell expands affixes eagerly on construction, and European
Portuguese's 1,340 rules over 44,257 stems want over a gigabyte of browser
heap — ~340 MB for the first 12,000 entries, and no return at all after three
minutes on the whole file. So the expansion runs once at build time instead:
1,039,058 forms, 2.66 MB gzipped, read by the same nspell in 842 ms.

The obvious npm package would also have shipped the wrong language. Both
dictionary-pt and dictionary-pt-br carry VERO, the Brazilian word list, so
vendoring by name puts pt-BR spellings behind a pt-PT label — the drift
SUGGESTIONS §3 warns about, arriving through the packaging where no reviewer
can see it. The source is Projecto Natura's, and the build script now asserts
the fault lines (receção in, recepção out) before writing anything.

Spellcheck consults both dictionaries and flags only what both reject, which
is the no-detector answer to a pair with no script boundary. The word card
does the same in the other direction: "data" is a word in both languages, so
Petal shows both readings rather than guessing which she meant.

Writing the tests caught the one real bug — extendedAlphabet was a snapshot
while correct/suggest read live, and her dictionary arrives after English, so
every lookup would have resolved "cora" while the underlines were already
right.

Not done, and not claimed: the pack has not been read by a pt-PT speaker, and
the Piper voice is deferred with the deploy.

Claude-Session: https://claude.ai/code/session_016y6gyuHkQXPiEuW8RGQyua

internal/lexicon/lexicon.go

@@ -47,6 +47,35 @@ type Result struct {
 	// Latin roots with English — "ephemeral" is much easier to keep once you
 	// have seen efémero next to it.
 	Etymology string `json:"etymology"`
+
+	// Reverse is the same token read as a word of the writer's own language,
+	// present only when it is one. Absent for every writer whose pair is not
+	// Latin-script, and for the overwhelming majority of words in one that is.
+	Reverse *Reverse `json:"reverse,omitempty"`
+}
+
+// Reverse is a lookup in the other direction: the token treated as a word of the
+// writer's language, translated into English.
+//
+// It exists because a Latin-script pair has no script boundary to tell the two
+// halves apart. In English+Chinese, "which language is this word?" answers
+// itself. In English+Portuguese it does not: *sale*, *casa*, *comum*, *tarde*
+// and *ali* are all real words on both sides, and *chat* and *pain* are the
+// French versions of the same trap.
+//
+// Petal does not guess. It asks both directions and shows whatever comes back,
+// which needs no detector, cannot be wrong about someone's writing, and — for a
+// learner — is more interesting than a correct guess would have been.
+type Reverse struct {
+	// Lang is the language this reading is in, so the card can label it.
+	Lang string `json:"lang"`
+	// Gloss is the English meaning of the native-language word.
+	Gloss string `json:"gloss"`
+	// Definitions are the word's senses as written in the writer's own
+	// language — the monolingual half, for when the English gloss isn't enough.
+	Definitions []Meaning `json:"definitions,omitempty"`
+	// Phonetic is IPA for the native-language pronunciation; "" when absent.
+	Phonetic string `json:"phonetic,omitempty"`
 }
 
 // unknownDifficulty is the [Result.Difficulty] value meaning "no score",
@@ -59,6 +88,10 @@ const unknownDifficulty = -1
 type GlossResult struct {
 	Word  string `json:"word"`
 	Gloss string `json:"gloss"`
+	// Reverse is the English meaning of the word read as one of the writer's
+	// own language — the tooltip's half of the both-directions rule (see
+	// [Reverse]). Empty unless the token is a word in her language too.
+	Reverse string `json:"reverse,omitempty"`
 }
 
 // maxSynonyms caps how many synonyms we hand the popover, even though the dataset