fix: wrap card creation in transaction to prevent race condition

[Midoriya-w]

Summary

Fixes a race condition in card creation where concurrent requests could create multiple default cards for the same user.

Changes Made

• Wrapped card count check and card creation inside a single Prisma transaction
• Replaced app.prisma.card.count with transactional tx.card.count
• Replaced app.prisma.card.create with transactional tx.card.create
• Ensured atomic execution of the default-card creation logic

Why This Fix Is Needed

Previously, the count check and card creation were executed as separate database operations. Concurrent requests could both read cardCount === 0 and create multiple cards marked as isDefault: true.

Using a Prisma transaction removes the race window and preserves data integrity.

Result

• Prevents multiple default cards from being created concurrently
• Maintains consistent user card state
• Improves backend reliability under concurrent requests

Closes #333

[ShantKhatri]

How come multiple return statements inside single function?

[Midoriya-w]

hey @ShantKhatri Refactored the transaction callback to use a clearer control flow with a single explicit final return statement for better readability and maintainability.

Updated in the latest commit.

[ShantKhatri]

hey @ShantKhatri Refactored the transaction callback to use a clearer control flow with a single explicit final return statement for better readability and maintainability.

Updated in the latest commit.

Now we have so many unnecessary changes, that's not acceptable. If that repeats continuously, will need to close the PRs.

[Midoriya-w]

hey @ShantKhatri Cleaned up the PR and removed unrelated changes. The branch now contains only the minimal transaction fix required for resolving the race condition issue.