Adds eight Hungarian / Central European news outlets to the RSS proxy allowlist:

  telex.hu      news (independent / largest readership)
  index.hu      news (mainstream domestic)
  hvg.hu        news / weekly current affairs
  444.hu        news / commentary
  24.hu         news (general)
  hirado.hu     public broadcaster (MTVA)
  portfolio.hu  business / finance
  www.atv.hu    political talk and news

CEE is currently under-represented in the allowlist — every existing
European entry leans north or west of Vienna, so a Hungarian-language
user (or any analyst tracking the V4 region) misses the bulk of native
coverage on Ukraine spillover, V4 governance, Paks nuclear, and the
Druzhba / TurkStream energy stories.

Synchronised across all four mirrors of the allowlist:
  shared/rss-allowed-domains.json   (source of truth)
  scripts/shared/rss-allowed-domains.json
  api/_rss-allowed-domains.js
  vite.config.ts  (RSS_PROXY_ALLOWED_DOMAINS dev-mode duplicate)

Pure data-only change; expected to pass the existing CI typecheck/lint
suite without source modifications.

Co-Authored-By: Claude Opus 4.7 <[email protected]>
Signed-off-by: zionappp-ui <[email protected]>

Follow-up to 208948e — the previous commit allowlisted the 8 HU domains
but left them un-wired, so they would not actually surface in news panels.

- Add 8 entries to `world:` block with lang: 'hu' so locale boosting picks
  them up via getLocaleBoostedSources('hu').
- Telex, Index.hu (24ora/rss), HVG, 444.hu, 24.hu, Portfolio.hu, ATV use
  direct native RSS (probed: 10-350 items per feed, content-type XML).
- Híradó (MTVA): hirado.hu has no working RSS endpoint — every /rss/* path
  returns HTML. Uses news.google.com/rss/search?site:hirado.hu fallback,
  matching the existing Kathimerini / Proto Thema pattern in this file.
- SOURCE_TYPES entries: 'mainstream' for news outlets, 'market' for
  Portfolio.hu (business/finance).
- source-tiers.json (both byte-identical mirrors): tier 2, matching the
  Polish / Turkish / Dutch convention so HU outlets are not deprioritized
  to default tier 4 (aggregator).

vite.config.ts:569 lists `portfolio.hu` (bare), but rssProxyPlugin's
dev-mode check uses strict `RSS_PROXY_ALLOWED_DOMAINS.has(parsed.hostname)`
with no www-normalization. Feed URL was `https://www.portfolio.hu/...`
so `npm run dev` returned 403.

Switch to `https://portfolio.hu/rss/all.xml`. The host issues a 301 to
the www form, which both transports follow transparently:
- Vite dev fetch() uses `redirect: 'follow'` (only the initial host is
  checked against the allowlist).
- Prod api/rss-proxy.js uses `redirect: 'manual'` + `isAllowedDomain()`
  which www-normalizes, so `www.portfolio.hu` matches `portfolio.hu`.

All other Hungarian feed URLs already have hostnames that exactly match
their allowlist entries; only Portfolio had the bare/www mismatch.

…edirect

`scripts/ais-relay.cjs:9467` re-checks redirect targets via strict
`RSS_ALLOWED_DOMAINS.has(redirectHost)` with no www-normalization —
same policy as vite dev, different from production's
api/rss-proxy.js `isAllowedDomain()` which DOES normalize.

The bare `https://portfolio.hu/rss/all.xml` URL we ship issues a 301
to `https://www.portfolio.hu/...`. Edge proxy + vite dev handle this
fine (Edge normalizes, vite uses `redirect: 'follow'` on the underlying
fetch so the redirect target isn't re-checked against the Set). But on
the Railway relay path (manual redirect-following inside ais-relay),
the 301 target lands on a strict Set lookup that returns false and the
relay returns 403 "Redirect to disallowed domain".

Add `www.portfolio.hu` to all four allowlist mirrors so the redirect
re-check passes on the relay path:
- shared/rss-allowed-domains.json (source of truth)
- scripts/shared/rss-allowed-domains.json (byte-identical mirror)
- api/_rss-allowed-domains.js (Edge ESM wrapper)
- vite.config.ts RSS_PROXY_ALLOWED_DOMAINS (dev-mode Set)

Audited the other 7 Hungarian feed URLs with curl -I -L; only Portfolio
crosses host on redirect. All others stay on their initial hostname,
which already exactly matches their allowlist entry.

… lang: 'hu'

Two P2 review findings on PR koala73#3857:

1. **Unsupported locale gating**. The 8 Hungarian feeds were tagged
   `lang: 'hu'` in `src/config/feeds.ts`, but 'hu' is not in
   `SUPPORTED_LANGUAGES` (src/services/i18n.ts:15) and no
   `src/locales/hu.json` exists. `fetchCategoryFeeds()` in
   `src/services/rss.ts:334` hard-filters `feeds.filter(feed => !feed.lang
   || feed.lang === currentLang)`, so `getCurrentLanguage()` can never
   return 'hu' and the per-feed fallback path filtered every Hungarian
   feed out for every user.

   Dropped the `lang: 'hu'` tag client-side. NewsItem.lang for badge
   rendering is sourced from the server digest entries (which DO tag
   `lang: 'hu'`, see below). Reasoning comment added inline.

2. **Server digest mirror gap**. `loadNewsCategory` at
   `src/app/data-loader.ts:919-947` returns the digest branch when
   `digest?.categories[category]` exists and never falls back to per-feed
   for client-only sources. The europe digest is served from
   `server/worldmonitor/news/v1/_feeds.ts`, which previously had no
   Hungarian entries — so even with the lang fix, the full-variant Europe
   panel would never receive Hungarian items in production.

   Added the 8 Hungarian entries to `VARIANT_FEEDS.full.europe` with
   `lang: 'hu'` (server-side metadata propagates to NewsItem.lang for
   the badge in NewsPanel). Híradó uses `gn('site:hirado.hu when:2d')`
   matching the existing server `gn()` convention (en-US locale params);
   the other 7 use direct RSS, matching the client-side routing exactly.

Verification:
- `tests/feeds-client-server-parity.test.mjs` — passes both
  "every NEW shared feed name uses consistent routing" and
  "no NEW server-only feed entries" checks.
- `npm run typecheck` — clean.
- `node --test tests/edge-functions.test.mjs` — 183 tests green; mirror
  parity holds.

Addresses PR koala73#3857 review P1: server-side `listFeedDigest()` filter at
`server/worldmonitor/news/v1/list-feed-digest.ts:998` is
`feeds.filter(f => !f.lang || f.lang === lang)`. Tagging server entries
`lang: 'hu'` without registering `'hu'` as a supported UI locale hid the
Hungarian feeds from every user — `req.lang` comes from
`getCurrentLanguage()` which can only return values in
`SUPPORTED_LANGUAGES` (`src/services/i18n.ts:15`).

Fix: register `hu` as a first-class locale, matching the existing
pattern for Tagesschau (de), ANSA (it), NOS Nieuws (nl), SVT (sv) where
the feed is locale-gated AND the locale is in the supported set.

- `src/services/i18n.ts:15` — add `'hu'` to `SUPPORTED_LANGUAGES`.
- `src/services/i18n.ts:170+` — add `{ code: 'hu', label: 'Magyar', flag: '🇭🇺' }`
  to LANGUAGES so it appears in Settings → Language.
- `src/locales/hu.json` — Hungarian translation file generated via the
  project's existing `scripts/translate-locales.mjs` (Claude Haiku 4.5):
  2555 strings, 0 rejected, full i18next interpolation tokens preserved.
- `scripts/translate-locales.mjs` — add `'hu'` to LOCALES + LANG_NAMES so
  future backfill runs maintain the locale.
- `scripts/sync-offline-translations.mjs` — add `'hu'` to LOCALES.
- `src/config/feeds.ts` — restore `lang: 'hu'` on the 8 Hungarian feed
  entries (matches the server-side tag; now that hu is a supported
  locale, the client `fetchCategoryFeeds` per-feed-fallback filter
  works for Hungarian-locale users).

Hungarian-locale users now see Hungarian UI translations AND the 8
Hungarian feed sources in the Europe panel. Other-locale users do not
see Hungarian feeds (locale-gated, matching the Tagesschau/ANSA
convention). This intentionally diverges from the original PR's
'CEE coverage for English users' framing in favor of the established
locale-gating pattern.

Verification:
- `npm run typecheck` clean.
- 206 tests across edge-functions + feeds parity + importance-score
  parity all green.
- `node scripts/translate-locales.mjs --only=hu --dry-run` reports
  `still-missing-after-run 0`.

Two review catches from PR koala73#3857:

1. **P2 — Híradó digest used en-US Google News for a Hungarian source.**
   `server/worldmonitor/news/v1/_feeds.ts:47` was `gn('site:hirado.hu when:2d')`
   which hard-codes `hl=en-US&gl=US&ceid=US:en`. Empirically the en-US
   edition returns 6 items for `site:hirado.hu when:2d`; the hu-HU
   edition returns 100 items. For Hungarian-locale users (the only
   audience that sees this feed via the digest's lang filter), this was
   a 16× quality cut.

   Add a sibling `gnLocale(q, hl, gl, ceid)` helper alongside the bare
   `gn()` and use it for Híradó with HU params. Helper avoids inlining
   the URL literal and is available for future locale-gated GN-fallback
   feeds. Server URL now matches the client-side hu Google News URL.

   Updated `tests/feeds-client-server-parity.test.mjs:75-79` to widen
   the "is Google News" detector regex from `\bgn\s*\(` to
   `\bgn(?:Locale)?\s*\(` so client direct-URL ↔ server `gnLocale()`
   are recognized as the same routing.

2. **P3 — offline.html missing hu locale.** After adding hu to
   `scripts/sync-offline-translations.mjs:21 LOCALES` in commit
   e37665f, I didn't actually run the script. `public/offline.html`
   still had no hu entry in its inline translation table, so Magyar
   users hitting the offline page fell back to English.

   Ran `node scripts/sync-offline-translations.mjs` — script reports
   "OK — wrote 22 locales into public/offline.html". hu entry now
   present, populated from src/locales/hu.json.

Verification:
- `npm run typecheck` clean.
- 206 tests across edge-functions + feeds-client-server-parity +
  importance-score-parity all green (parity test now passes with the
  widened regex).
- Empirical: 100 items returned from hu-HU Google News vs 6 from en-US.
- offline.html has 22 locale entries (was 21).

PR koala73#3857 review P2: locale-boost migration at App.ts:736-748 derived
userLang from navigator.language ONLY. A user on an English browser who
picks Magyar (or any non-browser locale) in Settings → Language would
never get the locale boost — the migration's first run with
`userLang='en'` sets the per-locale guard key (`worldmonitor-locale-
boost-en`), and the `userLang !== 'en'` short-circuit means the boost
block never re-fires for any subsequent explicit-locale choice. Result:
Hungarian feeds remained in `disabledFeeds` for explicit-Magyar users,
and `loadNewsCategory()` filtered them out via `enabledNames.has(i.source)`
even though the server digest carried them.

Fix: read `wm-locale-explicit` localStorage key directly before falling
back to navigator. Mirrors the i18n.ts:99 `wmExplicit` detector
semantics. Direct localStorage read (not `getCurrentLanguage()`) because
the migration runs inside the App constructor BEFORE `initI18n()` is
called from `init()` — i18next isn't initialized yet.

Behavior matrix after the fix:

| Setup | userLang | localeKey | Boost runs? | Result |
|---|---|---|---|---|
| Browser=en, no explicit | en | -boost-en | No | (default — HU disabled) |
| Browser=en → user picks Magyar | hu | -boost-hu (new) | Yes | HU re-enabled |
| Browser=hu, no explicit | hu | -boost-hu | Yes | HU enabled on first load |
| Browser=hu → user picks en | en | -boost-en | No | (default — HU disabled by user choice) |

Verification:
- `npm run typecheck` clean.
- 188 tests across edge-functions + feeds-client-server-parity green.
- Per-locale guard keying means existing users who already ran the
  migration with browser=en still re-enable HU sources on first reload
  after picking Magyar (the `-boost-hu` key is a different localStorage
  slot, never written before the fix).

PR koala73#3857 review P3: src/utils/map-locale.ts:LANG_TO_TILE_FIELD had no
hu entry, so getLocalizedNameField('hu') returned 'name:en' for
Magyar-locale users and map labels stayed in English.

Adds `hu: 'name:hu'` to the mapping. OSM has well-populated `name:hu`
tags worldwide (Hungarian is a major OSM tagging language —
significantly more coverage than the `vi` case noted at line 24 as
"not available in Protomaps/OSM tiles"). Protomaps tiles inherit this
from OSM source data, so the fallback chain in
getLocalizedNameExpression() (`['coalesce', ['get', 'name:hu'], ['get',
'name:en'], ['get', 'name']]`) correctly serves Hungarian labels where
they exist and gracefully falls back to English / the canonical name
for features without a Hungarian tag.

Single-line addition. No tests added — this slot is exercised by the
existing localizeMapLabels flow which has integration coverage via the
map shell init path; unit-testing this 1-line registry entry would be
brittle.

…locales pro-test skip

Two review catches from PR koala73#3857 round 9:

1. **P2 — Hungarian feeds disabled again by free-tier cap.** For free-
   tier hu users, the locale-boost migration re-enabled HU feeds; then
   `enforceFreeTierLimits()` ran `selectSourcesUnderCap()` over all
   FEEDS without filtering to current language. Since Hungarian entries
   sit AFTER the existing en/de/it/nl/sv defaults in the europe[] array,
   the round-robin walked them last and the cap auto-disabled all 8 for
   the default free-tier Hungarian experience.

   Added optional `protectedNames: ReadonlySet<string>` param to
   `selectSourcesUnderCap()` — names seeded into `keep` before round-
   robin, counted against the cap (no unbounded expansion), guaranteed
   not to be auto-disabled. User-disabled names still win (filtered out
   of buckets before the seed step). Names not in any bucket silently
   ignored.

   `enforceFreeTierLimits()` now derives userLang from
   `wm-locale-explicit || navigator.language` (same derivation as the
   locale-boost migration fixed in `540fdb255`) and passes
   `getLocaleBoostedSources(userLang)` as `protectedNames`. Result:
   free-tier hu users keep their Hungarian sources; the cap eats into
   en/de/it/nl/sv defaults instead.

   3 new tests: protectedNames seed behavior at production-shaped
   scenario, user-disabled wins over protected, ignored unknown names.

2. **P3 — translate-locales.mjs --pro-test crashes on missing locale
   file.** The unified LOCALES array serves both the main app
   (`src/locales/`) and the pro-test bundle (`pro-test/src/locales/`),
   but the two roots are independent. After adding 'hu' to LOCALES in
   `e37665f8c`, --pro-test mode threw at `readFileSync('pro-test/src/
   locales/hu.json')` because the file doesn't exist.

   Adds an `existsSync()` guard before reading each locale file — skips
   silently for locales the active root doesn't have. Matches the
   reviewer's "derive locale list from selected root" suggestion in
   spirit without inverting the script's iteration model. Avoided the
   alternative placeholder-file fix because adding an empty
   `pro-test/src/locales/hu.json` would change the pro-bundle's lazy-
   loaded chunk graph, triggering the `enforce-pro-test-bundle.mjs`
   pre-push freshness gate without a corresponding `cd pro-test &&
   npm run build` step.

Verification:
- `npm run typecheck` clean.
- 26 source-cap tests pass (3 new + existing).
- 206 tests across edge-functions + feeds-client-server-parity +
  importance-score-parity green.
- `translate-locales.mjs --only=hu --dry-run`:
  - default: `[hu] ✓ already complete`.
  - --pro-test: `[hu] (no file at pro-test/src/locales/hu.json; skipping)`.