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.

frontend/src/views/SettingsView.vue

@@ -12,6 +12,10 @@ interface SettingItem {
   label: string;
   description: string;
   group: string;
+  // Ints only, and nullable: the server sends the registry's bounds so the number
+  // input can refuse an out-of-range value before the round trip.
+  minimum: number | null;
+  maximum: number | null;
 }
 
 const config = useConfigStore();
@@ -131,10 +135,16 @@ onMounted(load);
               :checked="Boolean(it.value)"
               @change="it.value = ($event.target as HTMLInputElement).checked"
             />
+            <!-- min/max come from the registry. The server rejects out-of-range
+                 values regardless — this is so the browser says so first, rather than
+                 letting someone type a hop count that would disable a protection and
+                 only learn about it from an error banner. -->
             <input
               v-else-if="it.type === 'int'"
               :id="it.key"
               type="number"
+              :min="it.minimum ?? undefined"
+              :max="it.maximum ?? undefined"
               class="w-28 rounded-lg border border-neutral-300 bg-white px-3 py-2 text-sm text-neutral-900 shadow-sm focus:outline-none focus-visible:ring-2 focus-visible:ring-brand dark:border-neutral-700 dark:bg-neutral-800 dark:text-neutral-100"
               :value="Number(it.value)"
               @input="it.value = Number(($event.target as HTMLInputElement).value)"