Fix race condition in notification status upsert

[Copilot]

The createNotifiedArticleStatus method used a find-then-insert/update pattern that was vulnerable to a race condition: two concurrent transactions could both observe no existing row and both attempt an insert, causing a unique constraint violation on user_id.

Changes

• Atomic upsert via native SQL: Replaced the find-then-insert/update logic with a single INSERT ... ON DUPLICATE KEY UPDATE query in UserNotificationStatusRepository, eliminating the race condition at the DB level.
• Service simplification: createNotifiedArticleStatus now delegates entirely to upsertLastNotifiedArticleId — no JPA findByUserId call, no branching.

// Before
userNotificationStatusRepository.findByUserId(userId)
    .ifPresentOrElse(
        status -> status.updateNotifiedArticleId(articleId),
        () -> userNotificationStatusRepository.save(new UserNotificationStatus(userId, articleId))
    );

// After
userNotificationStatusRepository.upsertLastNotifiedArticleId(userId, articleId);

INSERT INTO user_notification_status (user_id, last_notified_article_id)
VALUES (:userId, :notifiedArticleId)
ON DUPLICATE KEY UPDATE last_notified_article_id = VALUES(last_notified_article_id)

---

🔒 GitHub Advanced Security automatically protects Copilot coding agent pull requests. You can protect all pull requests by enabling Advanced Security for your repositories. Learn more about Advanced Security.