hub v0.119.0 — English households get English words for their codes (R-597); R-596/R-598 closed

The setup code and the owner passphrase now follow the household's language,
one word longer in English so the entropy never drops (setup 3 hu / 4 en,
passphrase 5 hu / 6 en). List and count are chosen together so a caller cannot
pair an English list with a Hungarian count. Hungarian is byte-unchanged.

Three claims in the row were wrong and are recorded as such:
  - the RECOVERY CODE is minted by felhom-agent from the EFF list and has
    always been English; the hub does not own it and no row was added.
  - no claim mail states a word count; the only count wording was the bind
    page's passphrase hint, whose English half is now count-free.
  - the proposed phone-safe filter removes 68% of the list (5270 of 7772
    words) and was measured, then declined, with the reason in source.

Also: guide_quote_gate binds the English volunteer guide's three quoted
messages to the controller's English bundle — nothing did, so the guide would
have gone on quoting Hungarian after the fix. Seven decoys, all convicting,
including the name-for-fact one.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0159rPz1ZhFKsS53msqPYxtS

documentation/architecture/05-hub-architecture.md

@@ -356,3 +356,50 @@ token is real. Pinned by `TestBindExpiredIsAlwaysDefaultLanguage`.
 56 goldens captured from v0.117.0 before any string moved, in
 `hub/internal/notify/testdata/mail_goldens/hu/`, with the English set beside them. The claim is a
 diff, not a reading. A golden is never regenerated to make a change pass.
+
+### 15.6 The CODES a household types, per language [hub v0.119.0, R-597]
+
+A mail in English that carries three Hungarian words with accents is not an English mail. The 2026-09-20
+drill received exactly that, and could paste the code but not read it to anyone.
+
+**Two secrets this repo mints follow the household's language**, list and word count chosen together
+by `configgen.RandomPassphraseFor(lang, use)`:
+
+| Secret | hu | en | who calls it |
+|---|---|---|---|
+| Setup / reset code | 3 words, 44.6 bits | **4 words, 51.7 bits** | `claim.Engine` via `CustomerLanguage` |
+| Owner passphrase | 5 words, 74.3 bits | **6 words, 77.5 bits** | the three `configs.go` sites |
+
+**The rule is per use: English ≥ Hungarian, in bits.** The English list (EFF large, 7772 words after
+filtering) carries 12.92 bits/word against the Hungarian list's 14.85, so English takes one more
+word. The test computes both sides from the embedded lists rather than comparing a constant with
+itself, so shrinking a list or lowering a count fails.
+
+**A third secret is NOT minted here and must not be added.** The customer **recovery code** is minted
+by `felhom-agent` (`internal/escrow`) from the same EFF list, ten words, ≈129 bits — it has been
+English since it was written. R-597's row listed it here; that was wrong. Writing a row for it in
+this table would create a second definition of a secret the hub does not own, which is the drift
+`backupTargetAbsentText` already demonstrates across two repos.
+
+**Which language, and when.** The setup code follows `Store.CustomerLanguage` — the same order the
+mail carrying it follows (reported → created-with → `hu`), so a code and its e-mail can never
+disagree. Two consequences, both deliberate:
+
+- **A household created as `hu` whose box later reports `en`** keeps every code already issued
+  exactly as it was; the **next** code issued is English. A code is a hash on the box, never
+  retranslated.
+- **At customer creation there is no stored customer yet**, so the Owner passphrase generated on that
+  form reads the language from **the form field**, not from `CustomerLanguage` — which would answer
+  Hungarian for every English household created. The store's `createdLanguage` applies the same
+  default to an absent value, so the two agree.
+
+**The box needs no change for any of this.** It stores and compares a bcrypt hash of whatever was
+minted and has no notion of which list the words came from — pinned by the controller's
+`TestClaimAcceptsAnEnglishWordCode`. The TTL, the single-use generation and the five-attempt lockout
+are untouched and language-blind.
+
+**Count wording.** No claim mail states a word count; they say `Setup code: %s`. The only place a
+count appeared was the bind page's passphrase hint, and its English half is now count-free ("The word
+phrase you received from your operator during setup") — because "five words" stops being true for an
+English household, and was already wrong for one whose passphrase predates this release. The
+Hungarian „öt szó" is correct and unchanged.