F182 packs: Spanish + Tagalog UI-language packs (subset, machine-drafted) — stacked on #233

[mforce]

Adds Spanish (es) + Tagalog (tl) UI-language packs and turns the language selector on (Account → Preferences now offers English / Español / Tagalog).

⚠️ Stacked on #233 (the i18n foundation) — base is f182-i18n-spa. Merge #233 first, then this.
⚠️ Machine-drafted translations, PENDING NATIVE-SPEAKER REVIEW (each pack file says so). See "Native review" below.

Scope — subset, honest

Only the already-externalized surface is translated: login, sales, Account → Preferences, and validation error messages. Every other screen (and the rest of the Account screen, e.g. the password section) still renders in English — the full string sweep of the ~18 remaining screens is tracked in #182. So a Spanish/Tagalog user sees those 4 areas localized and the rest in English (English is the fallback for every not-yet-translated string).

What this adds

• web/src/i18n/es.ts, web/src/i18n/tl.ts — mirror en.ts's 104 keys exactly (en.ts stays the typed source of truth). Header notes mark them machine-drafted + list the intentional loanwords.
• web/src/i18n/index.ts — SUPPORTED_LANGUAGES = ["en","es","tl"]; exports a single RESOURCES = { en, es, tl } used by both init and the parity test.
• LanguageSelector — display names (English / Español / Tagalog); the selector now renders (it was hidden while English-only).
• catalogParity.test.ts — asserts each pack has exactly en's key set (a missing key = silent English fallback → test fails) and the same {{placeholder}} + tag structure per value (so a future edit can't drop {{ref}} or break the <Trans> markup undetected). Self-registering off RESOURCES.
• Docs: CONTRIBUTING-i18n.md "adding a pack" steps; HelpPage prose + a "UI language" in-app glossary entry; GLOSSARY.md updated.

Native review

I generated these; they need a native speaker before real users see them. Structurally verified (parity + placeholders intact, no leftover English in translated slots after the fix wave), but flag for review:

• es: unitFlat = "Cubeta" (regional — cubeta/maple/panel); a few mildly stilted phrasings.
• tl: unit/payment nouns kept as PH-register English loanwords (Flat, Tray, Case, Carton, Bank Transfer, Cash, Card) and "Reference"; methodCheck = "Tseke" (vs "Cheke"); atMostDecimals has no plural form (pre-existing i18n limitation).
• UI screen/label names inside sentences (e.g. "(Customers page)") are deliberately kept in English in both packs, because those screens aren't translated yet — the instruction should point at what's actually on screen.

Review

4-way per policy — codex + two Claude agents + pi. All confirmed the packs are structurally sound (en.ts unchanged, parity real, placeholders intact, no locked coverage threshold touched, tests strengthened not weakened) with no Critical/Important code defect. Their findings were folded in a fix wave: the parity test now guards placeholders/tags + is self-registering; the 4 accidental-looking Tagalog leftovers were resolved (customer → "Kustomer"; the loanwords documented as intentional); the in-app glossary entry added; the "Account screen translated" wording narrowed to "Account → Preferences." A scoped re-review confirmed all fixes (including a mutation test proving the parity guard catches a dropped placeholder).

Testing

npm run test:coverage 651 tests green; coverage above the (unchanged) floors; npm run typecheck clean; npm run build succeeds. New tests: catalog parity (keys + placeholders + tags), es/tl language resolution, the now-visible 3-language selector.