fix: add database-level UniqueConstraint to Favorite model

[ayushshukla1807]

This PR adds a UniqueConstraint to the Favorite model across the user_id, entry_id, and campaign_id columns.

Why:

In a previous fix (#540), we discovered that favorites were leaking across campaigns because they were only scoped to user + entry. This database-level constraint ensures data integrity at the schema level, preventing duplicate favorites from ever being created.

Impact:

• Prevents duplicate Favorite rows in the database.
• Explicitly documents the intended identity of a Favorite record.
• Future-proofs the model for cleaner migrations.

This resolves the underlying database task mentioned in Issue #541.

[lgelauff]

Why would a database level constraint be desirable exactly? Wouldnt if be sufficient to deal with it at the backend? Is this a pattern you see in existing code?

[ayushshukla1807]

I saw some duplicate rows in the favorites table during my audit. Application-level checks are fine, but they fail during race conditions (like a user double-clicking 'favorite'). A DB-level constraint is just standard practice for data integrity. I didn't see it much in the existing schema, but that's exactly why we have these data leakage bugs.