Add a web Directory workspace to view and edit person attributes

[salmonumbrella]

The situation

The people model on main is now much richer than anything the web shows. Since #531 the following have merged with authenticated APIs and generated clients: portable attribute definitions and typed, historized attribute values (#535); structured names, contact points, addresses, dates, media, categories, and service-scoped observations with ETag-guarded patching and explicit history (#565); reviewable identity-match candidates (#596); organizations and employment (#593); typed temporal relationships (#592); dated activity and computed contact state (#599). #621 adds the vCard envelope, #628 proposes fact candidates and briefs, and #622 adds the person Media and Files gallery.

The web has a Relationships workspace — RelationshipsWorkspace, RelationshipHeader, RelationshipList, RelationshipTimeline, LinkIdentityDialog, PersonTimeline — built on Svelte 5 and @kenn-io/kit-ui. GET /api/v1/people/{id} returns a profile block when the cluster is promoted. That is the whole person surface. There is no component under web/src/lib that reads or writes an attribute, a definition, a contact point, an address, a date, a category, an employment, or a typed relationship; those endpoints exist only in web/src/lib/api/generated/schema.d.ts. #532 lists the web exposure deferred from #531 — promote, list, rename, delete, and the person_binding_conflict handling in the link flow.

#534 step 17 is "Expose the resulting model through the web Directory and bounded network views." This issue is that step.

What works today, and why it is not enough

Everything is reachable through the CLI (msgvault person attributes set|list --history, attribute-definition create|list) and through the generated clients. That is fine for agents and scripts. It is not how a person maintains a contact. Someone who wants to see what msgvault knows about a contact — current employer, partner's name, the last time they talked, which channel to use — and correct one field, has to leave the browser. And a profile you cannot see is a profile you do not trust; the sweep in #628 will propose changes that need a place to be reviewed.

Ask

Add a Directory workspace to the web app that shows every typed fact about a person and lets the user change them, using the components and patterns the app already has.

• Directory list: browse and search promoted persons, sorted and filterable by contact state (last contacted, primary channel), category, and organization; promote a cluster to a person from here (the Person profiles: web UI exposure and read-side integration (follow-up to #531) #532 item).
• Person detail, one page, sectioned by the typed model rather than by table: names; contact points grouped by service with the observation that backs each one; addresses; dates; categories; media; attributes rendered from their definitions — type, cardinality, choices, sensitivity — including user-defined fields; organizations and employment as a timeline; typed relationships in both directions; contact state and the feat(activity): add dated contact activity #599 activity summary; the Add a scheduled people sweep that keeps curated attributes current from the archive #628 brief and "last time we talked" when present. The feat(web): add person attachment galleries #622 Media and Files gallery mounts here as a tab.
• Edit in place: set, supersede, and close attribute values with the history kept and shown; add and correct contact points, addresses, dates, categories; add and end employments and relationships; rename; ETag/If-Match on every write with person_revision_conflict handled as "reload and retry", not a generic error. Define a new custom field from the UI through the attribute-definitions API.
• Review queues in the same shell: identity-match candidates (feat(beeper): add reviewable identity candidates #596) with accept/reject, and, once Add a scheduled people sweep that keeps curated attributes current from the archive #628 lands, fact candidates with accept/reject/unsure and the rejection memory. The link flow's person_binding_conflict gets the resolution path Person profiles: web UI exposure and read-side integration (follow-up to #531) #532 asks for, which becomes the merge action once person merge exists.
• Bounded network view: a person-centred projection of typed relationships and shared organizations to a configurable depth, built from the relationship and employment APIs, not from message co-occurrence.
• Build on what exists: @kenn-io/kit-ui components and the RelationshipsWorkspace patterns for layout, dialogs, tables, and errors; the generated API client only; no new endpoints unless a gap is found, in which case the gap is its own small PR against the API first.

Design constraints: read-side behaviour identical against SQLite and PostgreSQL because everything goes through the API; sensitive attributes are visible but marked and never auto-filled; nothing in the UI writes an attribute without provenance (source=user, actor); fixtures and screenshots use synthetic identities.

Delivery boundary

Owns the web Directory workspace, person detail, in-place editing, review queues, and the network view. Does not add or change API contracts except to fill a discovered gap. #622 owns the Media and Files tab and mounts into this shell. #628 (f) is the fact-candidate review UI and lands inside the review queue here. #532's web items are covered by this issue; its read-side integration and unbinding items are not.

Refs #534, #531, #532, #535, #565, #592, #593, #596, #599, #621, #622, #628.

[salmonumbrella]

@wesm need you here because it's frontend design

[wesm]

Noted, I can spend some cycles on this soon