feat: custom profile avatars + profiles that reach share recipients

[crs48]

What

Custom avatars. Settings → Profile gains a Picture field: uploads are center-cropped, downscaled to 192px, and re-encoded through a canvas (which strips EXIF/GPS metadata) into a small inline `data:image/*` URL stored on the Profile node — one sync path for name and picture, no blob authorization needed across share boundaries. The top-left profile button, profile menu/sheet, mobile shell, and editor header show the picture when set; without one they show the deterministic DID identicon (the "default genmoji"), via a shared `SelfAvatar` component. The profile menu now shows your display name instead of "You".

Profiles in shared contexts. Share recipients used to see `did:key…` fragments and identicons for every author, because Profile nodes never reached them (the "hub-published" intent in `auth-exempt.ts` was never implemented). Now:

• A DID's canonical Profile lives at the deterministic `profileNodeId(did)` (`profile-`, mirroring `inbox-`), so knowing a `createdBy` DID is enough to acquire the author's profile. `ProfileSettings` writes there; a one-time idempotent migration in `CommsProvider` copies legacy random-ID profiles over.
• The hub treats profile rooms as hub-published identity: any authenticated DID may subscribe/read (`authorize.ts`, source `profile-public`); only the subject DID may write — enforced on both the node-change and Yjs write paths (`ShareAccessService`).
• A new `useEnsureProfiles(dids)` hook acquires missing profiles on sight, wired into channel chat, threads, channel rosters, page comments, presence facepiles, and the ShareDialog People tab (which now shows names + avatars instead of raw DIDs).
• `usePageComments` gains an optional `resolveAuthorName` — the existing `authorDisplayName` plumbing in the comment UI was always there, just never fed.

Security reflection

Sharing something with someone implies they can see who you are — so profiles (display name, handle, avatar, status) are readable by any authenticated DID on the hub, matching the "public identity" intent already documented in `auth-exempt.ts`. Per-share profile ACLs can't work anyway: a recipient needs the profiles of all authors in a doc, not just the sharer. Guard rails added:

• Write protection: hub rejects profile-room writes from any DID other than the subject.
• Spoof resistance: `dedupeProfiles` prefers self-authored profiles (`createdBy === did`), so a write-role grantee can't override someone's identity by injecting a Profile node into a shared doc (foreign-authored profiles still fill gaps — the devtools seeder relies on that).
• Avatar sanitization: `safeAvatarSrc` only lets `data:image/*`, `http(s):`, and `blob:` through to ``; profiles sync from untrusted peers.
• Metadata hygiene: canvas re-encoding strips EXIF before the picture leaves the device; anonymous hub sessions get no profile-public allowance.

Tests / verification

• `profileNodeId` determinism + round-trip, 64k avatar field (inbox-state.test.ts)
• Hub: subject-only writes, authenticated-read allow, anonymous deny, non-profile rooms unaffected (share-links.test.ts — full suite green)
• `safeAvatarSrc` allow/deny matrix, spoof-preference + fallback in `dedupeProfiles`
• Live-verified in the worktree preview: upload → 2.2 KB WebP data URL → top-left avatar shows the picture, persists across reload; identicon fallback intact.

Changeset: `@xnetjs/data` minor (new `profileNodeId`/`didFromProfileNodeId` exports; `avatar` maxLength 500 → 65536, a loosening). Hub/editor/app are private packages.

🤖 Generated with Claude Code

[github-actions]

Preview removed for PR #465.

[github-actions]

🖼️ UI changes in this PR

Screens

✏️ Home _(SSIM 0.972)_

before	after	diff

Interactions

🎬 Open a channel and post a message

▶ Watch MP4

🎬 Create a page and use the editor

▶ Watch MP4

_{Auto-captured by CI · run. Informational — not a blocking check.}