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.

.env.example

@@ -39,18 +39,10 @@ POSTGRES_PASSWORD=
 # 127.0.0.1 so only the proxy can talk to it.
 #THOUGHTSYNC_BIND=0.0.0.0
 
-# How many proxies sit in front of this app. This is a SECURITY setting, not a
-# preference: it decides which entry of X-Forwarded-For is believed, and therefore
-# whether a caller can forge their own address and slip the per-address rate limit.
-#
-#   0  nothing in front — the app is directly exposed
-#   1  one reverse proxy terminating TLS (the default, and the usual case)
-#   2  a CDN in front of that proxy, e.g. Cloudflare
-#
-# Set it to the number you actually run. Too HIGH is the dangerous direction — it
-# starts trusting entries no proxy of yours wrote. Too low just means callers share
-# a rate-limit bucket.
-#THOUGHTSYNC_TRUSTED_PROXY_HOPS=1
+# NOTE: how many proxies sit in front of this app is a SETTING, not an env var —
+# Settings → Security → "Trusted proxy hops" in the admin UI. It defaults to 1 (one
+# reverse proxy terminating HTTPS) and belongs there because it is something you may
+# need to change while the server is running, alongside the sign-in limits.
 
 # How much the app says. Credential events (sign-ins, failures, throttles, new
 # accounts, device tokens issued) are logged at INFO and read with