Document the Prisma partial-index drift on Ticket_email_sourceId_key

Ticket_email_sourceId_key is a partial unique index, created in raw SQL on #170's branch:

CREATE UNIQUE INDEX "Ticket_email_sourceId_key"
ON "Ticket"("sourceId")
WHERE "source" = 'EMAIL' AND "sourceId" IS NOT NULL;

Prisma's schema language cannot express a WHERE clause on @@unique. So the index exists in the database and in the migration history, but has no representation in schema.prisma.

The failure mode

prisma migrate dev compares the schema against the database, sees an index it cannot account for, and reports drift. The suggested resolution is typically to drop it. Someone tidying up a drift warning, in good faith, removes the constraint that stops Postmark retries creating duplicate tickets — and nothing fails, because the guard it backs is a belt-and-braces read that usually catches the retry first.

Silent loss of a correctness guarantee, triggered by following the tool's advice.

What to do

Cheapest useful step is a comment in schema.prisma on the Ticket model, naming the index, saying it is intentionally raw-SQL-only, why Prisma cannot express it, and what breaks if it is dropped. A future reader hitting the drift warning then has the context at the point of decision.

Worth considering alongside:

• Whether other raw-SQL objects have the same exposure. The Message(ticketId, responseKey) unique index on #170's branch is expressible in Prisma, so it is likely fine — worth confirming rather than assuming.
• Whether a CI check should assert the index still exists, so its removal fails loudly instead of silently. A single pg_indexes query in a migration test would do it.
• Documenting the same trap in whatever contributing/migrations guide exists, since the next partial index will hit it too.

Related: #169 proposes more partial unique indexes for the other inbound doors, which would multiply this.

Start in schema.prisma at the Ticket model and inspect the existing migration history for the raw SQL creating Ticket_email_sourceId_key. Add a comment naming the partial index, explaining why it is raw-SQL-only and what breaks if it is dropped. If time permits, confirm the Message(ticketId, responseKey) index is expressible in Prisma and check the contributing or migrations guide for the same warning.