feat: propose and approve hashtag channels (user management part D)

[efiten]

Part D of #2128: logged-in users propose a hashtag channel, an admin approves, rejects or later revokes it, and the ingestor decrypts approved channels without a restart. It is the first consumer of a generic proposal table, and answers the request in #2092.

Stacked on #2138 (part C). Review the commits after that branch; GitHub shows C's commits here until it is merged.

The situation

• An instance decrypts only the hashtag channels listed in hashChannels. Users who want a city or club channel shown have to ask the operator, who edits config.json and restarts the ingestor.
• Feature proposal: user-suggested shared hashtag channels with admin approval and revoke #2092 asked for a suggest-and-approve flow; a downstream fork (feat(channels): shared hashtag channel proposals, with admin revoke dborup/CoreScope#99) runs one with anonymous suggestions and a file queue.

What this PR adds

Name rules (internal/channel). ValidateHashtagName, mirrored in the browser:

• at most 31 UTF-8 bytes including # (firmware ChannelDetails.name[32]), case preserved, Public refused in any case;
• control, bidi, separator and format characters refused except ZWJ, plus invisible fillers (Other_Default_Ignorable_Code_Point, U+2800, non-ASCII spaces).

Go and JS give the same verdict for every code point.

Store. Schema v4, one generic proposals table (kind, subject, status pending/approved/rejected/revoked, proposer, reviewer, note). One row per (kind, subject); limits are checked in the same transaction as the change.

Server (only with userManagement.channelProposals.enabled)

• POST /api/proposals, GET /api/account/proposals, GET /api/admin/proposals, POST /api/admin/proposals/{id}/approve|reject|revoke.
• 400 for an invalid name. 409 for a duplicate, a rejected name, or a name already in hashChannels/channelKeys ("this channel is already decrypted on this instance"). 429 over a limit (maxPending 100, maxApproved 128, perUserPerDay 5).
• GET /api/channels gains approvedChannels, so approved channels are listed before they have traffic. With the feature off the response is byte-identical.

Ingestor. Opens users.db with mode=ro every 60 seconds, re-validates the names, and swaps its key map through an atomic.Pointer. Configured channels always win, and a failed read keeps the last good set. The ingestor never writes users.db; AGENTS.md now says so.

Frontend. "Propose for everyone" in the add-channel dialog, an "approved" marker in the channel list, "My proposals" on the account page, and an admin "Proposals" tab with a warning on approve. The packet detail pane now escapes the channel name: until now only the operator chose those names.

Spec: docs/specs/2026-10-07-channel-proposals-design.md.

Performance

Every key is tried on each GRP_TXT that no key opens (decodeGrpTxt). Benchmark of that worst case:

Keys	Time per packet
320 configured	204 to 216 µs
320 configured + 128 approved	272 to 320 µs

That is about +33%, linear in the key count and capped by maxApproved. With the feature off the decoder gets the identical map and no ticker runs.

Verification

• internal/channel, internal/users (with -race), cmd/server and cmd/ingestor pass locally, 53 new Go tests. The ingestor's TestWriteStatsAtomic_SymlinkAtDestIsReplaced needs symlink rights on Windows and fails on master too.
• sh test-all.sh exits 0; the XSS gate in diff mode passes.
• User-management E2E: 21 of 21 steps locally (propose, approve, the channel appears, revoke removes it).
• On our staging and production instance since 7 October 2026.

Not in this PR

• Private (PSK) channels: their keys stay in the browser (feat: user-configurable channels in web UI + DB-backed message history #725).
• Anonymous proposals.
• Names that need ZWNJ (some Persian and Urdu spellings) and subdivision flags are refused, because ZWNJ and tag characters are format characters. Allowing them later only widens the rule, so no approved name gets stranded.