[WIP] Improve group feature of Skychat, both on features and infrastructures

[mrpalide]

Did you run make format && make check? Yes

Fixes #_

Changes:

• add group admission control — join requests, approval queue, kick/ban/mute/read-only
• reject stale roster/admin/mod gossip — replaying an old signed leaf silently undid evictions
• let an invite name several admins — join requests pointed at OwnerPK alone, so an offline founder meant nobody could join
• promote/demote from the members panel — the RPC existed, nothing called it, so a group could never get a second admin
• rotate the group key on eviction — a ban took the seat but left the key, so a copy of the feed kept opening
• seal group keys at rest — groups.db handed over every private group's AES key to anyone who could read the file
• serve group history from any online member, not just admins — admin-toggleable per group, choosable at create time
• price and rate-limit joining — free public keys meant a flood could outrun any per-PK gate, including ban
• bound compromise in time — DH-ratcheted epoch keys for DMs, ephemeral wraps and age/volume rotation for groups
• fix CI — realistic per-package test timeout, and move DmsgVisorRPCPort off a port the visor already binds
• encrypt governance gossip — roster/admin/mod leaves are signed but plaintext, so who you banned and muted is readable even in an encrypted group
• encrypt group file bytes — messages are sealed, attachments aren't; files ride the backfill path with no group-key encryption
• "ask again" after a declined request — denial is terminal by design, so the UI needs an explicit retry button
• retention / disappearing messages — no TTL, no expiry; data accumulates forever and delete-for-everyone is cooperative
• metadata reduction — SenderPK and exact timestamps sit in the clear beside the ciphertext, and the federated topology exposes the subscription graph

How to test this PR:

Browser, against three real visors:

make e2e-build && make e2e-run && make e2e-skychat

then, across the three UIs it prints:

1. Create a private group on visor A. Invite link alone should NOT let B in —
   B lands in A's approval queue; approve it and B gets the key with the
   approval, not from the link.
2. Create a public group. The link alone should be enough, and the first join
   should visibly cost a moment (proof-of-work) rather than being instant.
3. Ban B from the private group. B loses the seat AND stops being able to read
   new messages; A's admin panel shows the key epoch advance. Older messages
   stay readable for everyone still in.
4. Promote C to admin, take A offline, then have a fourth visor join using the
   same invite link — C should be able to admit it.
5. Open a DM between two paired visors and send one message each way. The chat
   header should move from "encrypted · keys not exchanged yet" to
   "forward secret · key " once both sides have spoken.