fix(dm): owner-only group DM ops accept federated target identification

Transferring ownership or kicking a member surfaced "Target user is not a
member of this DM channel" whenever the target was a federated user.

Root cause: the client passed `canonical.id` from `useCanonicalUserView`,
which returns the user's HOME id when the home view is in the userViews
cache. After owner-routing the request to the owner instance, that
instance's `dm_members.userId` (its own local replicated id) never
matched the home id, so `isDmMember` returned false. The same failure
mode applied across any cross-instance scenario where the
channel-serving instance and the owner-serving instance disagree on the
local replicated user id for the same federated user.

Fix: both endpoints now accept federated identification, mirroring the
existing pattern on `POST /api/dm/:id/members`:

- `POST /api/dm/:id/transfer` body: `{ newOwnerId? } | { homeUserId, homeInstance }`.
  Federated args win when both are supplied (strictly more specific).
- `DELETE /api/dm/:id/members/:targetUserId` reads optional
  `?homeInstance=<origin>` query; when present, the URL segment is
  treated as a homeUserId and resolved via `resolveOrCreateReplicatedUser`.

Client `api.dm.kickMember` and `api.dm.transferOwnership` gain an
optional `federated` argument; `DmRosterPanel` and `MobileGroupDmInfo`
pass it whenever the target has `homeUserId` + `homeInstance` populated.

Adds 5 server tests (3 transfer + 2 kick) covering federated targets,
the federated-wins-over-local precedence rule, and federated-non-member
rejection. Updates 2 client routing tests and 2 DmRosterPanel test
assertions for the new signature. Updates `docs/systems/dm-system.md`
and `docs/systems/api.md`.

Server: 965 tests pass (was 960). Web: 362 tests pass (was 360).

packages/shared/src/types.ts

@@ -594,6 +594,23 @@ export interface AddDmMemberRequest {
   homeInstance?: string;
 }
 
+/**
+ * Body of POST /api/dm/:id/transfer.
+ *
+ * Accepts either a local user id (`newOwnerId`) or a federated identity
+ * (`homeUserId` + `homeInstance`). Federated identification mirrors
+ * `AddDmMemberRequest` and is required when the caller only knows the
+ * target's home identity — typical for federated members surfaced through
+ * the client's `userViews` cache, where `id` is the home id and not the
+ * owner instance's local replicated id. When both are supplied, the
+ * federated args take precedence (strictly more specific).
+ */
+export interface TransferOwnershipRequest {
+  newOwnerId?: string;
+  homeUserId?: string;
+  homeInstance?: string;
+}
+
 export interface GroupDmUserIdentity {
   id: string;
   homeUserId?: string | null;