fix(upstream): adopt PoracleNG 5.2.1's fort hook and availableLanguages

[hokiepokedad2]

Adopts two upstream fixes shipped in PoracleNG 5.2.1 (jfberry/PoracleNG#197). Both of our workarounds were still running against a server that no longer needs them. Both upstream issues — #194 and #195 — are now closed as completed.

1. fort in disabledHooks, and one fewer call — fd2e46c

PoracleDisabledHookMap gains ["fort"] = DisableFeatureKeys.FortChanges, and the second GET /api/config/values probe for general.disable_fort_update is now made only when the server is too old to report fort.

Detection is the presence of the availableLanguages key, not a version number. It shipped in the same release as fort, and its presence is a yes-or-no with no third reading. The alternatives are worse: version is a string needing semantic comparison, and an empty disabledHooks is ambiguous — nothing disabled, or too old to say.

One subtlety worth reading: a config read that failed leaves the question unanswered, so the probe is still made. Assuming "new" on a failure would stop honouring the flag on every 5.1.0 the moment Poracle hiccuped. Everything still fails open, per the rule in CLAUDE.md that a Poracle outage must not disable every alarm type for everyone.

The doc comments were rewritten rather than left. The pokestop paragraph now says it was vestigial, is gone from the array as of 5.2.1, and stays unmapped for older servers that still send it; the disable_fort_update paragraph now describes the second call as an older-server fallback rather than a permanent necessity. Stale comments explaining a workaround that no longer applies are the lie the next reader believes.

Correcting the upstream prediction

The issue said this "should let you drop that second /api/config/values call entirely". It does not, quite: disable_showcase is still absent from disabledHooks on 5.2.1, and that endpoint is the only place to read it. Verified on both servers — disable_showcase is present in /api/config/values on 5.2.1 and absent on 5.1.0.

Net effect on 5.2.1: three upstream calls per probe become two. Adding showcase to the array upstream would make it one.

2. availableLanguages — 3736c32

It governs the alert language, not the display language. Confirmed in PoracleNG's own code rather than assumed: both HandleSetLanguage (v1) and the v2 route validate the submitted code against available_languages case-insensitively and answer 422 "language is not available".

So it does not compose with our allowed_languages site setting, which restricts the display menu — they govern different things. AlertLanguageService.languages was already deliberately built from allLanguages rather than the filtered list, and that stays. The only intersection applied is against the eleven languages this UI has a flag row for, since a code we cannot render is not offerable regardless.

Semantics follow the upstream author's deliberate choice: key absent means an older server, null means unrestricted, a non-null array is the exact allow-list. Absent, null and empty all collapse to "unrestricted", which is right for both an unconfigured 5.2.1 and every 5.1.0.

• poracle_alert_languages is a projection, alongside poracle_locale — one shared config read, one cache entry. Upsert refuses it and PROJECTED_KEYS carries it, so it never reaches the admin page's "Other" catch-all as an editable box. Both halves are required: a stored row would win over the projected value permanently. See poracle_locale is editable in admin settings and one save pins it permanently #780 for the same mistake.
• Codes are shape-checked individually, so junk drops rather than poisoning the list.
• load() still reconciles against all eleven, so a stored choice predating a restriction is reported rather than silently reverted.
• The user-menu item hides itself when the intersection is empty.

No new user-facing strings — the empty case hides a control rather than explaining itself — so the eleven locale files are untouched.

Verified against both live servers

5.1.0 (:3040)   no availableLanguages key   disabledHooks: []   version 5.1.0
5.2.1 (:3042)   availableLanguages: null    disabledHooks: []   version 5.2.1

disabledHooks is empty on both because this deployment disables nothing, so a non-empty array could not be observed — the fort mapping rests on the upstream author's statement plus upstream's hookTypes construction. Neither server's config was touched and production was not contacted.

Tests

Backend 2595 (from 2582), frontend 119 suites / 1423 (from 1415), production build clean, ESLint and Prettier clean.

Every new test was watched red first, and each new-behaviour test is paired with a 5.1.0-still-works sibling — ServerWithoutAvailableLanguagesIsStillAskedForTheFortFlag, GetAllServesNoAlertLanguagesRowForAServerTooOldToReportThem, "should offer all eleven on a Poracle too old to say", "restricts nothing when Poracle is too old to report an allow-list". The fallback is the whole point of the change, so it is the half that most needed pinning.

CLAUDE.md is updated in both the upstream-flags and projections sections, and docs/features/internationalization.md now says whose list is whose.