fix: make prisma seed idempotent (#1094)

[Killerjunior]

Description

Re-running npx prisma db seed against an already-seeded database previously crashed with a unique-constraint violation (or silently created duplicate rows) because prisma.streamEvent.create() was used instead of upsert(). This PR makes the seed script fully idempotent by converting that call to upsert() keyed on the existing @@unique([transactionHash, eventType]) compound constraint, and documents the guarantee in the backend README.

Type of Change

• 🐛 Bug fix (non-breaking change which fixes an issue)
• 📚 Documentation update

Related Issues

Closes #1094

Changes Made

• backend/prisma/seed.ts — Replaced prisma.streamEvent.create() with prisma.streamEvent.upsert(), keyed on the @@unique([transactionHash, eventType]) compound constraint. All three seeded models now use upsert():

  Model	Unique key used for upsert
  User	publicKey
  Stream	streamId
  StreamEvent	transactionHash + eventType ← fixed

• backend/README.md — Added a "Database Seeding" section documenting the npx prisma db seed command and the idempotency guarantee with the table above.

Testing

Test Coverage

• Manual testing performed

Test Steps

1. Start a local Postgres instance and apply migrations: npx prisma migrate deploy
2. Run the seed once: npx prisma db seed — confirm it completes without errors.
3. Run the seed a second time against the same populated database: npx prisma db seed — confirm it completes without errors and no duplicate rows appear in User, Stream, or StreamEvent.
4. Verify row counts in each table remain the same after the second run (e.g. via npx prisma studio or a direct SQL query).

Breaking Changes

None. This change only affects the local development seed script. No schema changes, no API changes, no data migrations required.

Checklist

• My code follows the project's style guidelines
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• Any dependent changes have been merged and published
• I have checked for breaking changes and documented them if applicable

Additional Notes

The StreamEvent upsert is keyed on the transactionHash_eventType Prisma-generated name for the @@unique([transactionHash, eventType]) compound constraint already present in schema.prisma — no schema changes are needed. The update: {} body is intentional: on conflict, the existing row is left unchanged, which is the correct behaviour for immutable on-chain event records.