Let the directory learn the speakers your events already have

[EllAchE]

Stacked on #328 (event-person-names-20260817t2030) — it uses eventPersonName from that branch. GitHub retargets this to main when #328 merges.

sbek CRM-S1, run 2026-08-17T05-46-05 (major):

The org-level speaker directory and the per-event speaker roster are two separate stores with only a manual, one-directional bridge, while the directory's own subtitle claims otherwise. /crm reads 'Every speaker and contact your organization has worked with, across all events', yet it opened at 'Showing 0 of 0 contacts / Your speaker database is empty' even though the same speakers.csv had already been imported into an event roster earlier in the run — the CRM never learns about people who exist as event speakers. The only link is the contact record's 'Add to an event' button, which pushes org → event; there is no reverse sync, so edits made on the event speaker record do not flow back and the same person can exist as two unlinked records. An organizer arriving with existing event rosters finds an empty CRM and must re-import.

The fix

The directory adopts the speakers on every event the organizer runs, on read. Keyed by email, idempotent:

• a speaker the directory has never heard of becomes a contact, linked to the event they were found on
• a speaker it already had is linked, not duplicated
• a speaker already linked to that event is left alone
• a person on two events is one record with two links

planRosterAdoption is the pure half and holds all of that; adoptEventSpeakers does the reads and writes around it.

Adoption only ever adds. A contact the organizer has since renamed, re-companied or written a bio for is theirs, and a roster row is not entitled to overwrite it. Adopted records carry source: 'event roster' so they are distinguishable from ones typed in by hand.

Both entrances run it — the directory and the dashboard — because landing on either first should not show a database of nobody.

The contact lookup includes merged-away tombstones on purpose: contact_owner_email is unique across them, so a merged row still holds its address and inserting over it would fail rather than adopt.

What this does not do

The enrolment half of the finding is closed. The edit half is not: renaming someone on an event speaker record still does not update their directory contact. Which store wins on a conflicting edit is a product decision, and picking one silently inside a bug fix would be the wrong place to make it.

Cost

One extra read on the two CRM entry points, and writes only on the first visit after a roster changes — after that the plan comes back empty and nothing is written.

Tests

lib/services/crm.test.ts gains 7 cases on planRosterAdoption: adopts an unknown speaker and records the event; does nothing the second time; links rather than duplicates someone already in the directory; one record and two links for a speaker on two events; adds only the missing event for a partially-linked speaker; keys the address case-insensitively (the column is stored lowercased, so a case-sensitive key would adopt twice); skips a participant with no address rather than guessing.

lint, typecheck, test (2051 in 190 files), build, docs:openapi, docs:mcp all clean.

Not merged and not deployed.