Phone App: finish the admin screen; translate the last English strings

Three loose ends from the last two commits, each of which was named as
deliberately-not-done and none of which is worth carrying further.

The phone's create-user sheet had no organization picker. The endpoint has
taken an `organization` since orgs existed and the Web App has offered the
choice all along, so a superadmin on the phone could only ever create
accounts in their own org - a silent restriction rather than a stated one.
The sheet now loads the orgs and offers them to a superadmin, with the same
blank "no organization" option and the same hint as the web. An admin still
gets no picker, because the server forces its own org on their members and a
picker that cannot change the outcome is a lie. The listing is manager-only
and can fail, in which case the picker offers only "no organization" rather
than blocking the form.

A locked role picker or delete action was greyed out with no reason given.
The web has explained itself in a title attribute since those guards existed,
and the sentences - admin.cantChangeOwnRole and the rest - have been sitting
translated in the phone's own language files since the screen was translated.
Hover has no touch equivalent, so the two controls take different routes: a
long-press on the role picker shows the reason as a tooltip, and the overflow
menu carries it under the action, because a disabled menu item cannot be
long-pressed and silently greying it out is the thing being fixed.

settings.integrations.* and charging.control.* were English-only in *both*
apps - 70 keys, identical text, identical key sets - so they are translated
once and land in all four language files. OCPP and CSMS are protocol names
and stay; product names (Toyota Connected, MyToyota, Anker Solix, Lexus) stay;
everything else follows the wording already in each language's file.

The Web App's files are edited as text rather than round-tripped through a
JSON dump, because they keep a blank line before every nested block and a
dump flattens it - a 900-line translation file is hard enough to read
without losing its paragraphs. Both diffs are purely additive as a result.

Both apps now have every key in all three languages: 738 in the web, and the
phone reports zero fallbacks. A new test locks that in - every key en.json
carries must exist in pl.json and da.json - and it was checked by deleting a
key and watching it fail, because a guard that cannot fire is not a guard.

Verified by flutter analyze (clean), flutter test - 21 pass, 1 of them new -
flutter build apk --debug, and npm run build for the Web App. The key checker
reports 575 static t() keys in the phone and 738 in the web resolving with no
fallbacks in either language.

Not verified: still nothing run against a live API Server or on a device. In
particular the organization picker's happy path - a superadmin creating an
account into a chosen org - has not been exercised end to end; it is the one
piece here that touches the API rather than only the language files.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

TRANSLATIONS.md

@@ -81,10 +81,13 @@ No screen code changes are needed to add a language.
 
 ## Coverage
 
-- **Web App** — fully translated (every view, component, form, and the status
-  labels in `lib/format.js`), except the Integrations settings and the OCPP
-  charger-control card: `settings.integrations.*` and `charging.control.*` exist
-  in `en.json` only, so both fall back to English in Polish and Danish.
+- **Web App** — fully translated: every view, component, form, and the status
+  labels in `lib/format.js`.
+Both apps are complete in all three languages. The one place the wording is
+deliberately not translated is proper nouns: protocol and product names (OCPP,
+CSMS, Toyota Connected, MyToyota, Anker Solix, Lexus) read the same in every
+file, as do the units.
+
 - **API Server panel** — UI chrome, cards, login, status, and the API section
   titles are translated. The individual REST endpoint **descriptions** in the
   API reference table are intentionally left in English as developer reference
@@ -102,12 +105,11 @@ No screen code changes are needed to add a language.
   data out as table columns), client-side validation (the web leans on the
   browser's `required`), and the snackbars.
 
-  Still English: the same `settings.integrations.*` / `charging.control.*` gap
-  the web app has, which is worth closing in both at once rather than letting the
-  phone run ahead.
-
-  `test/models_format_test.dart` guards the lookups the analyzer cannot see —
-  the ones built from a key at render time (`car.tabs.$key`,
-  `enums.fuelType.$v`, the delete dialog's plural counts, the connected
-  service's readings). A catalogue entry with no label fails the test rather
-  than reaching a screen as a raw key path.
+  `test/models_format_test.dart` guards two things the analyzer cannot see. The
+  lookups built from a key at render time (`car.tabs.$key`, `enums.fuelType.$v`,
+  `admin.roles.$r`, the delete dialog's plural counts, the connected service's
+  readings) must resolve to a real label in every language — a catalogue entry
+  with no translation fails the test rather than reaching a screen as a raw key
+  path. And every key `en.json` carries must exist in `pl.json` and `da.json`,
+  so a phrase added in English alone is caught at the point it is added rather
+  than by whoever next reads a half-translated screen.