Phase 20: the dictionary stops being English and Chinese only

Word lookups now come from DreamDict's dict.db for every pair but Chinese —
opened read-only beside petal.db, no service, nothing over the VPN, because a
hover gloss has to answer in milliseconds.

`Provider` is the two questions the popover and the tooltip already asked, so
the embedded *Lexicon satisfies it with no changes at all; Set.For(lang) is the
single place the choice between them is made. The prerequisite in the dreamdict
repo turned out to be two things, not one: the module path was unfetchable
*and* the query layer sat in internal/, which no other module may import
whatever the module is called. Both fixed upstream.

The plan's central assumption did not survive the data. It mapped
Gloss ← Translate(word, "en", L1) one-to-one; against the real 452 MB database
that table answers for 17% of the 2,000 commonest English words into pt-PT.
Wiktionary's translation sections are thin in that direction — "ephemeral",
"think" and "quickly" have no en→pt-PT row at all. Shared WordNet synsets
answer for 61%, so DreamDict gained Equivalents() and Petal glosses through it.
Ordering those was wrong in an instructive way too: sorting by frequency
glosses "think" as lembrar, "remember", because lembrar is the commoner
Portuguese word even though pensar shares six of think's synsets to lembrar's
one. Counting sense agreement first asks the right question.

The same measurement is why zh stays on ECDICT: DreamDict reaches a Chinese
gloss for 53% of those words, ECDICT for nearly all of them. The plan said
converge only if quality holds. It didn't, so nothing converged.

Two decisions about failure worth keeping. A missing dict.db is not an error —
a laptop checkout has never had one — but a present-and-never-imported one is,
because that is a half-finished deploy. And a pt-PT writer with no dictionary
falls back to the embedded datasets with the gloss suppressed, keeping
definitions, synonyms and phonetics rather than blanking the popover: an empty
field reads as "not found", the wrong language reads as broken.

The new fields surface as an etymology line and a three-band chip. Three, not
five: the difficulty score separates "everyday" from "you'll have to explain
this" but cannot rank obfuscate against serendipity, and a finer scale would be
a confident-looking lie. An unscored word gets no chip.

Writing the tests found two bugs first — trimEtymology sliced by byte, which
would have emitted invalid UTF-8 for exactly the Greek and Latin etymologies
the feature exists for, and its ellipsis path overran its own cap.

go build/vet/test, tsc, vite, vitest 96/96 clean; live smoke against the real
dict.db with one instance flipped from zh to pt-PT mid-run.

Not deployed: go.mod still replaces github.com/prosolis/dreamdict with
../dreamdict, so the Docker build needs the two upstream commits pushed and the
replace dropped. The deployed dict.db also predates DreamDict's Spanish data.

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

MULTIUSER_PLAN.md

@@ -252,6 +252,17 @@ almost 1:1 onto `lexicon.Result`:
 It also carries data Petal has no equivalent for and could use: `Antonyms`,
 `Frequency`, `Difficulty`, and `Etymology`.
 
+> **Correction (2026-07-27, Phase 20).** The `Gloss` row of that table is wrong.
+> `Translate(word, "en", L1)` reads Wiktionary's translation sections, which are
+> thin in the en→X direction: measured on the real `dict.db`, it answers for
+> **17%** of the 2,000 commonest English words into pt-PT and 16% into fr.
+> Meaning has to come through shared WordNet synset ids instead (**61%**), which
+> is what DreamDict's new `Equivalents(word, from, to)` does — falling back to
+> the translations table, for 62% combined. The 1:1 mapping was assumed from the
+> API surface and never checked against the data; it did not survive contact
+> with it. Same measurement on zh reads 53% against ECDICT's near-total coverage
+> of those words, which is why the zh pair did **not** converge.
+
 So Phase D stops being gated on data and becomes an integration decision.
 
 ### OPEN #6a (new): how to integrate — **SETTLED: Option 3** (ratified 2026-07-26)