Security values move into the Settings UI

Operator: *"proxy hops defaults to 1 and should be in the settings UI not in the
envs, we need the security values to be in the UI."* Overrules the call I made
yesterday, and rule 25 is on your side — I argued deployment-topology, but the
operator has to be able to SEE what protects them, and reading a container's
environment is not seeing.

Six new settings in a **Security** group: trusted proxy hops (default 1), the
per-account and per-address sign-in limits with their shared window, and the
sign-up limit with its own. `THOUGHTSYNC_TRUSTED_PROXY_HOPS` is gone; the rate
limits are no longer hardcoded constants.

**The hard part was keeping the throttle cheap.** It consults these BEFORE opening
a database connection — deliberately, because a refused attempt is meant to cost
nothing, and the hop count is needed to know who is even asking. A query per
attempt would undo both. So there is a small cache seeded from the registry
defaults (the app works with no database at all, which is what the DB-free unit
lane relies on), loaded at boot, and refreshed on every settings save — the same
live-update contract `session_ttl_days` already had.

`SlidingWindow` now takes its limit and window as SUPPLIERS rather than values, so
a saved number applies to the next attempt instead of the next deploy.

**Bounds are rejected, not clamped.** A hop count of 99 would trust anything a
caller sent; a sign-in limit of 0 would lock every account out permanently. Both
now fail validation with a message naming the range, and the number input carries
min/max so the browser objects first. Silently storing a different number than the
one typed is how somebody ends up believing a protection is set to something it is
not.

`MAX_BUCKETS` stays a constant on purpose: it protects the limiter from itself
rather than the app from a caller, and there is no operator judgment to apply.

Two integration tests, because the whole point is the round trip: a dangerous
value refused, a legitimate one reaching the cache the throttle reads and
persisting; and every Security row reaching the admin payload with bounds and a
description that explains itself.

docs/public-hosting.md

@@ -41,9 +41,10 @@ Once a browser has seen HSTS from your hostname it will refuse plain HTTP there
 year, even if the header stops. That is the point of it, but it is worth knowing
 before you put a hostname behind TLS temporarily.
 
-**3. Tell it how many proxies are in front of it.** `THOUGHTSYNC_TRUSTED_PROXY_HOPS`
-defaults to `1` — one reverse proxy terminating TLS. Behind a CDN as well (Cloudflare
-in front of your proxy) set it to `2`.
+**3. Tell it how many proxies are in front of it.** **Settings → Security → Trusted
+proxy hops**, which defaults to `1` — one reverse proxy terminating TLS. Behind a CDN
+as well (Cloudflare in front of your proxy) set it to `2`. It applies immediately; no
+restart.
 
 This decides which entry of `X-Forwarded-For` is believed, and it is a security
 setting rather than a preference. The header grows left to right as a request
@@ -74,9 +75,10 @@ docker run --rm -v thoughtsync-data:/d -v "$PWD":/out alpine tar czf /out/media.
 
 - **The credential endpoints are throttled.** `/api/auth/login`, `/api/auth/register`
   and `/api/auth/device-login` count attempts against both the account and the calling
-  address, and answer `429` with a `Retry-After` once either is over budget — ten
-  failed sign-ins per account per fifteen minutes, five registrations per address per
-  hour. The account-keyed limit is the one that holds when the address is forged.
+  address, and answer `429` with a `Retry-After` once either is over budget. The
+  numbers live in **Settings → Security** — ten failed sign-ins per account per
+  fifteen minutes and five sign-ups per address per hour by default — and a change
+  applies to the next attempt rather than the next deploy. The account-keyed limit is the one that holds when the address is forged.
   Checked *before* the password is verified, so a throttled attempt costs no bcrypt:
   hashing is deliberately slow, and an unauthenticated caller who can trigger it
   without limit has a CPU-exhaustion primitive as well as a guessing one.