feat(plugins): TREK_PLUGINS_IGNORE_TREK_RANGE turns the version gate into a warning (#2226)

* feat(plugins): TREK_PLUGINS_IGNORE_TREK_RANGE turns the version gate into a warning

A plugin whose author has not updated its `trek` range for the running TREK can
now be installed, updated and activated when the operator sets
TREK_PLUGINS_IGNORE_TREK_RANGE to a truthy value. Every gate (registry picker,
post-extraction re-check, sideload, dev-link, activation) warns instead of
refusing; a missing range is tolerated the same way; "install latest" takes the
newest published version. The plugin-API version gate is not lifted and the
Discover compatibility verdict stays truthful.

The admin is warned at every step: each bypass is logged, install/upload/link/
update responses carry a `trekRangeBypassed` marker, and both admin panels show
a "Version checks off" pill, an "Install anyway" confirm dialog before a
registry install, the same notice after a path that could not ask first, and a
persistent chip on the row while the plugin runs outside its range.

Nine new i18n keys in every locale; wiki pages updated (Environment-Variables,
Admin-Plugins, Plugin-Development, Security-Hardening).

* refactor(plugins): one useRangeBypass hook behind both admin shells

SonarQube flagged PR 2226 at 10.8% duplicated new code: the range-bypass
logic had been added to the desktop and phone plugin panels as identical
copies. The marker/warning types, the row chip, the "Install anyway" offer,
the dialog copy and the confirm-or-notice state now live in
useRangeBypass (next to useInstanceSettings, the existing shared-logic
precedent); each panel keeps only its own dialog/sheet markup.

* docs(claude): record the SonarQube gate rules and the no-English-placeholder i18n rule

The CI SonarCloud gate (Sonar way, on new code: >=80% coverage, <=3%
duplication, A ratings, hotspots reviewed) was only discoverable by waiting
20-25 minutes for the workflow. The root CLAUDE.md now states the conditions,
the desktop/mobile shell-mirror duplication trap and its shared-hook fix, and
how to check a PR with the sonarqube MCP first; client and server CLAUDE.md
point at it. shared/CLAUDE.md says every locale needs a real translation —
parity cannot tell an English placeholder from a translation.

* docs(claude): keep CLAUDE.md to commands, invariants, gates and philosophy

Verified every concrete claim in the five CLAUDE.md files against the code
and fixed the stale ones: the websocket server is the Nest realtime gateway,
MCP tools live in <domain>.mcp.ts files, the client "native shell" section
described code that was never written, offline maps also prefetch vector
basemaps, plus several renamed files and wrong table names.

Then trimmed everything that drifts on its own: dates, migration history,
counts, and inventories of stores, slices, domains, sync files and CLI
commands. What stays is the commands, the invariants with the file that
enforces each one, what CI actually runs, the reference implementations to
copy, and the rules for new code. Each file now opens with that rule.

wiki/Plugin-Development.md

@@ -1427,9 +1427,17 @@ The `trek` range is a **hard contract**, enforced in both directions:
   declared `<4.0.0` it now refuses to start. It stays installed and listed,
   switched off, with the reason shown (`TREK_VERSION_INCOMPATIBLE`; a plugin that
   declares no range at all reports `TREK_VERSION_UNKNOWN`).
-- **No admin override.** The range is the author's own statement that the plugin
-  does not work there — unlike a rotated signing key, there is nothing an operator
-  could verify out-of-band and wave through.
+- **One operator escape hatch, loudly.** The range is the author's own statement
+  that the plugin does not work there, so there is no per-install override in the
+  UI. An operator who is stuck on a plugin whose author has not yet updated its
+  range can set `TREK_PLUGINS_IGNORE_TREK_RANGE=1` on the server: every gate above
+  then warns instead of refusing (a missing range is tolerated too), "install
+  latest" takes the newest published version, each bypass is logged, the response
+  carries a `trekRangeBypassed` marker, and the admin sees a warning dialog plus a
+  persistent chip on the row. Nothing guarantees the plugin works there, and a
+  mismatched plugin can in rare cases corrupt TREK data — so ship the range bump
+  rather than telling your users to flip the switch. The plugin-API version gate
+  (`apiVersion`) is never bypassed.
 
 Two behaviours follow. "Install latest" resolves to the newest version *this* TREK
 can run rather than the newest published, so shipping a 2.0.0 that needs TREK 4