…ess tests

- `_parseFederate`: inline `_hostFromAuthority` null-check so the
  validated-but-unused `host` binding doesn't mislead readers into
  thinking `authority` (full authority incl. port) should have been
  replaced by the stripped hostname in the result.

- Add two missing avatar-resolution tests (server-relative path for
  remote user, space-scoped bare-hash override for remote member) that
  exercised an untested branch of `_userAvatarUrl`/`accordMemberAvatarUrl`.

- Add `lastIndexOf` edge-case tests for `parseFederatedAddress` and the
  `daccord://federate/` deep link so qualified space IDs (containing an
  embedded `@domain`) are confirmed to split on the final `@`.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01YHXe8ANc18KmzhtQyZ3Py9

Phase 3 of client federation: render and react to remote-homed messages
in shared spaces. M1–M2 already made every cache key on the full
qualified ID, so remote message create/edit/delete, reactions, and typing
flow through the existing gateway handlers unchanged. The gap this closes
is qualified-self recognition.

A remote home re-qualifies the local user's own actions to our domain
before fanning them back (`me` -> `me@a.example`), so a bare
`== currentUserId` stopped recognising them — self-notifying, self-chiming,
double-counting our own reactions, and showing "you are typing" on
ourselves on remote-homed channels/messages.

- accordkit: add `isSameUser(actorId, localId, {localDomain})` — matches a
  bare local id or our own id qualified to our home domain, while a remote
  actor that merely shares our bare snowflake stays distinct (#159).
- AccordServer.homeDomain + ref `watchHomeDomain()`: expose our federation
  home domain (the base URL host) to event handlers and the message pane.
- Event handler: route message author/mention, reaction ownership, and
  typing skip-self through qualified-aware self checks (#160–#162).
- Message pane: own-message and mention highlighting recognise our
  qualified id on federated messages (#159).

Remote author identity, avatars (home CDN), and the origin badge already
resolve via the qualified author_id -> member/user cache -> replica-fetch
path and the M1–M2 RemoteOriginBadge.

Tests: isSameUser (self vs. colliding-snowflake); message-cache dedup/
update/delete keyed by qualified id; federated reaction aggregation
(remote actor not-self, own-echo merges). flutter analyze + suites run in
CI (no Dart toolchain in this environment).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Phase 4 of client federation: open and render direct messages with users
on other servers.

Open by qualified handle (#163):
- A qualified recipient (`<snowflake>@<domain>`) now routes through the
  single `recipient_id` field so the server takes its cross-server DM path
  (deterministic home + replica mirror); bare ids keep the recipients-list
  same-server form. Extracted as `dmCreateBody`.
- New "Message remote user" entry in the DM list opens a dialog that
  validates a qualified handle (`isValidRemoteHandle`) before opening.
- The member popout's existing "Direct Message" already passes a remote
  member's qualified id, so messaging a visible remote member just works.
- `openAccordDirectMessage` now surfaces the server's rejection reason
  (federation disabled, recipient not qualified, peer untrusted, blocked)
  instead of a generic failure.

Origin-aware rendering (#164):
- DM list tiles and the conversation header show the participant's
  home-domain avatar (resolved against their home CDN) and a
  RemoteOriginBadge for cross-server DMs. The server stores our own DM
  participant with a bare id, so the 1:1 "other" participant resolves
  cleanly in both the home and replica channel cases.
- Send/receive use the (qualified or bare) channel id unchanged.

Tests: dmCreateBody routing + isValidRemoteHandle validation; accordkit
cross-server DM channel parse (qualified channel id + remote recipient).
Remote avatar/origin helpers were already covered. flutter analyze +
suites run in CI (no Dart toolchain in this environment).

Known limitation (pre-existing, parity with local DMs): the lightweight DM
dialog isn't a live gateway view — incoming messages and reactions/typing
aren't shown there for any DM, local or federated.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Audit follow-through focused on consistency, DRY, and clean organization:

- Add shared helpers: watchAccordClient(), list upsertById/removeById, and
  RestResult listOrLog/dataOrLog; adopt across controllers and views.
- Give AccordMemberAvatar an initialStyle param and route the remaining
  hand-rolled CircleAvatar sites (voice, forum, message row, etc.) through it.
- Extract the shared admin-tab body skeleton into AdminListScaffold.
- Move non-Riverpod helpers into the services/ convention: event handler ->
  events/services, sound + notification -> notifications/services,
  federation_join -> server/services.
- Rename the auth-state model accord_auth.dart -> accord_auth_state.dart to
  stop colliding with the AccordAuth repository.
- Enforce always_use_package_imports; fix the lone relative import and drop a
  dead commented-out class.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

The space tile menu only offered "Leave server"/"Leave & delete data", both of
which hit the server over REST and so fail for a server you can no longer
reach, leaving no way to clear it from the rail. Add a "Remove server" entry
that calls AccordAuth.removeAccount() — purely local cleanup (disposes the
client, clears saved credentials, rail entry, tabs, unread state and cached
spaces), so it works even when the server is unreachable. Confirms first and
notes nothing is deleted server-side.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>