fix(contacts): make first-contact upserts race-safe

[vladbisceanu]

Concurrent /v1/track requests can all observe a missing normalized contact, then race on contact.create. The unique (projectId, email) constraint elects one row, but the losing requests currently surface Prisma P2002 as 500s and drop their events.

This change treats P2002 as a successful election: each loser reads and continues with the elected contact. It does not replay stale persistent data or a default subscription state over the winner. Explicit opt-outs remain monotonic through a compare-and-set update, and only the request that actually changes subscription state emits the subscription event.

The gate evidence now forces eight parallel service upserts through the same missing-row observation and sends a twelve-request HTTP burst. The burst asserts twelve 200 responses, one normalized contact, twelve distinct durable events, and at most one active execution while the workflow is waiting. Both contact-winner orderings and stale concurrent unsubscribe observers are covered; the existing normalization and cross-project isolation suite remains green.

Verification:

• focused service + HTTP durability suites — 76 passed
• yarn lint — passed (0 errors; existing warnings only)
• yarn workspace api build — passed
• yarn test:run — 1,178/1,180 passed; two unrelated performance gates missed locally (49,909 vs 50,000 renders/s, and the existing 10k-contact benchmark timed out at 120s)
• yarn build — API and preceding packages passed; the unchanged landing workspace stopped the monorepo build with Could not parse output from TypeScript's --showConfig

Review note: two local concurrency review passes found an opt-out ordering edge and duplicate subscription-event emission from stale observers. Both are fixed and have dedicated regressions in this PR.

Portable upstream counterpart: useplunk#469

Closes #10