fix(infra): report which environment variable pins a setting

[rmyndharis]

The Infrastructure page decided a setting was pinned by an environment variable by comparing the running value against the saved file. That mismatch is also exactly what a save looks like before the server is restarted, so a stock stack with no variable set anywhere still told the operator that a variable was pinning the setting — and never said which one. The Engine card had no notice at all, so a pinned engine silently reverted after a restart and read as "nothing was saved", which is how it was reported in #1082.

Change

load-env snapshots the keys present immediately before data/.env.generated is merged — everything supplied by the container environment or a project .env. Both load with override: false and outrank the saved file permanently, so both are pins.

This is a second snapshot rather than a reuse of recordOsEnvKeys. That one answers "may this value win over the file being written?" for the save-config guard, where only a host value counts. This one answers "can the dashboard change this at all?", and there a project .env pins just as hard. Verified: with a pinning .env and no container variable at all, only the new snapshot reports it.

Because clearBlankEnv runs before the snapshot, a blank compose forward (- KEY=${KEY:-} with nothing set) is already deleted and correctly does not register as a pin — so the bundled compose keeps behaving exactly as before.

/infra/status reports the pinned subset of the four editable selection keys. The page then names the variable when a setting is pinned, says a restart is pending when it is not, and applies the same notice to the Engine card. envPinned is optional on the client type so a dashboard served by an older gateway degrades to the previous behaviour rather than breaking.

Verification

Unit tests cover the snapshot (a shadowing layer counts, a blank forward does not, and a real value that merely repeats the default does) and the controller wiring (only editable selection keys are reported, never unrelated variables like PATH).

Beyond the suites, the built app was run against four configurations and /infra/status inspected each time:

Configuration	envPinned
Nothing set	[]
Bundled compose, nothing set (ENGINE_TYPE=, REDIS_ENABLED=)	[], and the saved values apply
Real REDIS_ENABLED=true in the environment	["REDIS_ENABLED"]
Project .env with ENGINE_TYPE	["ENGINE_TYPE"]

The first two are the cases that previously produced a false pin notice.

Both new strings are translated across all twelve locales; i18n:check passes, including placeholder parity for the new {{name}} token.

Refs #1082.