#3435 [GUI] Use web API keys immediately when browser storage fails

Descripción

## Problem and result

The web app saves its API key only on `change` (usually blur), and every request reads it back from localStorage. Before blur, an edited key is not used. If storage is blocked or full, the app discards the entered key, sends no key (or the old one), and still says “API key saved.”

The page now uses the trimmed key immediately on input, saves it when possible, and keeps using it in memory if storage fails. On change, it warns that the key must be entered again after reload when persistence is unavailable. Clearing the field removes Authorization. Existing stored keys and keyless servers keep working.

Related symptom: #725. This fixes the client-side event/storage paths, not server-side key normalization proposed in the closed #956.

## Approach

Keep the current page's key in memory for the shared request-header helper. Have the existing storage setter report whether its write succeeded, so the notification does not claim persistence when the write failed. No new dependencies, server changes, authentication bypasses, or engine changes.

## Validation

Linux, Python 3.14.4, Node v22.22.1. Final commit: `3afe9d4a`.

Passed:
- `python3 -m unittest serve.test_web_api_key serve.test_web_sampling -v`: 12 tests passed (8 API-key regressions, 4 existing sampling tests).
- `node --check serve/web/app.js` and `git diff --check`.
- Before the fix, the initial regression run failed on missing/stale Authorization and the false success notification; the same cases pass after the fix.
- In Chromium against the running page at `127.0.0.1:8080`, confirmed input updates Authorization and storage without blur. With Storage reads/writes forced to throw, confirmed Authorization still uses the edited key, a warning appears, and clearing the field removes Authorization. Test values were removed afterward.
- Authenticated GET `/metrics` on the live server returned HTTP 200.

Failed / limits:
- Broader `.venv/bin/python -m unittest discover -s serve -t .` run, before adding the final notification regression: 888 tests, 2 failures, 14 skipped. Failures were `serve.test_keepawake.KeepAwakeTests.test_service_holds_for_the_whole_request_including_early_close` and `serve.test_responses.NoLeakedSampler.test_server_close_ends_the_sampler`. The keepawake failure also reproduces against an exported unmodified parent revision (`e88ee39d`); the sampler test passes in isolation on both revisions. Neither was changed here.
- A live chat request authenticated but returned HTTP 400: `verify: instantiate: out of memory`. A successful GPU-generated answer was therefore not verified; this PR does not address that engine memory error.
- `.venv/bin/python -m pytest -q` could not run: pytest is not installed. C++/GPU builds were not run because no backend files changed.