test(e2e) + fix(marketing): the social Messages surface e2e — and the two DM bugs it caught

[jacoby149]

What

The social-e2e lane's Messages bite: e2e/tests/social-messages.spec.ts — API floor (DM group contract + CRUD, deterministic DM group ID, I3 anti-test) + browser gauntlet (two-user DM round-trip through the real app: A composes to B → B receives → B replies → A's reload sees the reply, [social-dms] log sequence on both sides).

The two bugs it caught (fixed in-lane)

1. The DM surface was broken end to end. dms.ts derived the DM group as web10.app/groups/{first}/dm-{second} (the KB's well-known shape) and added members with provider-qualified keys (web10.app/users/{username}). Neither can exist: POST /v3/groups/create derives the group_id from the caller's token ({provider}/groups/users/{creator}/{name} — the well-known shape is only creatable by direct DB insert, like the boot-time discover group), and the node's user key is the bare username — so the provider-qualified member keys never matched the real users, the recipient was never a member, and every receive 403'd. Fix: the deterministic identifier is the group NAME dm-{sorted} (the messages-demo findDmGroup reference pattern) — both parties find the group by name suffix in their own group list; member keys are bare usernames; listConversations resolves the other party from membership (the name is ambiguous — usernames may contain dashes) with a member_count === 2 guard; readDms on a not-yet-existing conversation returns [] instead of 403.
2. isMe never matched. sender_provider derived from a bare author_key is the literal string web10 (extractProvider's fallback), never the node's provider, so the provider-qualified isMe comparison never matched in any environment — own messages rendered as the other party's (left-aligned, no edit/delete menu). Now username-based (v3 DMs are same-node): DmsScreen bubble, MailView thread + formatFromTo, CrmView, and classifyThread/replyAllTargets.

Out of lane (notes in .context/social-e2e-messages-handoff.md)

• groups.ts still exports the broken dmGroupId/ensureDmGroup; the same well-known-shape mismatch affects closeFriendsGroupId/ensureCommunity (the followers half was just fixed in fix(social) + test(e2e): the follows surface works + the groups e2e floor/gauntlet #703 with the provider-aware ID pattern).
• KB drift: db/clickhouse.md's user_blacklist/group_blacklist DDL is stale (code expects updated_at+deleted; a fresh CH built from the KB DDL 500s on every group read — the read path anti-joins both). And social-contracts.md's DM Group ID column is uncreatable via the API.

Verification

• Spec 4/4 green (API floor ×3 + gauntlet), run against an isolated e2e stack (the shared e2e compose project is contended by the sibling lanes — see the handoff note for the topology: isolated project + static nginx router + host-published port, the CI topology, because Chromium maps *.localhost → 127.0.0.1 for page navigations).
• tsc -b && vite build clean; 200 web10-social unit tests green; spec file tsc-clean (the pre-existing exporter/gauntlet/messages-demo tsc errors are untouched).
• Screenshots re-captured (chat/mail/crm/settings, desktop + 375px) — green run per the temporary no-PNG-read override in the harness README.