Fix transaction atomicity and race conditions in quota management

[Copilot]

Addresses critical concurrency and consistency issues in the quota management system introduced in PR #186.

Changes

• Transaction atomicity: Wrapped signal-based quota resets in transaction.atomic() to prevent partial updates across users
• Race condition handling: Replaced select_for_update().get_or_create() with proper get() → create() → IntegrityError → get() pattern to handle concurrent quota record creation
• Submission atomicity: Moved submission.save() inside transaction blocks to ensure quota decrements and submission creation succeed or fail together
• Filtering consistency: Standardized all assignment_id filtering to use assignment_id=None instead of mixed assignment_id__isnull=True

Example

Before (race condition):

# Two concurrent requests could both call get_or_create
# select_for_update only locks the SELECT, not the INSERT
quota, created = UserProblemQuota.objects.select_for_update().get_or_create(...)

After (race-safe):

try:
    quota = UserProblemQuota.objects.select_for_update().get(...)
except UserProblemQuota.DoesNotExist:
    try:
        quota = UserProblemQuota.objects.create(...)
    except IntegrityError:
        # Another request created it, fetch with lock
        quota = UserProblemQuota.objects.select_for_update().get(...)

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.