v0.1125.0

v0.1125.0 - saved servers survive relaunch; This PC gets its own home; the federation UX doc

Two field-test fixes from the first night of real multi-server use:

Saved servers persist now. The list lived only in runtime memory, so every
server added in the Chat sidebar or Relays rail VANISHED on relaunch; the
operator hit it the first evening two real servers existed to add.
AppConfig.saved_servers round-trips identity (name + url) with a test
locking the contract: identity survives, connection state stays runtime,
and configs from before the field existed apply cleanly.

Host a node on this PC stops masquerading as a server setting. It used to
render at the bottom of whichever remote relay was selected, reading as if
hosting were a feature OF that server. It now has a permanent THIS PC rail
entry (status dot: serving or not) whose selection opens its own dedicated
panel; remote relay pages no longer carry it.

And the design doc for where this is going: docs/design/federation-ux.md
records the operator's three taste calls (always-connected multi-server;
federated rooms render ONCE, merged, with a bridge badge; one unified
Servers concept for visiting and running) plus the operator's own best
idea, the COMMONS: a sidebar section for rooms bridged across two or more
of your servers, because a federated room belongs to its mesh, not to any
one server. Send routing through any healthy carrier makes federation's
whole point tangible: the room outlives any single server. Multi-
connection foundation is next.

Context: united-humanity.us and public.guide federated for the first time
tonight (mutual tier-2 trust, #general bridged, both directions verified
in production logs).

Verified: full battery + saved-servers round-trip test + 10 lints + both
feature checks; world entry panics=0.

Co-Authored-By: Claude Fable 5 noreply@anthropic.com