fix: prevent duplicate moodle_token insert when Moodle rotates token …

[y4nder]

…(#399)

Surfaced by the new error log page on staging — login for ucmn-t-67092 (and harvie) was failing with

duplicate key value violates unique constraint
"moodle_token_moodle_user_id_unique"
Key (moodle_user_id)=(5) already exists

The "rotated token" branch in MoodleTokenRepository.UpsertFromMoodle kept the existing row alive (just flipping isValid = false) and then called this.create(...) to insert a second row carrying the same moodleUserId. The column-level UNIQUE constraint on moodle_user_id rejected the insert at flush time → unhandled 500. Users whose token had not yet rotated (string-equal to the stored one) hit the second branch which updated in place and worked, which is why this was intermittent.

Two compounding factors:

1. The find was keyed by user.id. When the local User row was recreated with a fresh UUID (or the existing token was soft-deleted), the find returned null, the create-path ran, and the unique constraint still saw the orphaned row.

2. The global soft-delete filter hid candidate rows that would have matched, so an in-place mutation never happened.

Fix:

• Look up by moodleUserId (the unique key) with filters: { softDelete: false } so the find is resilient to rotated tokens, soft-deleted rows, and re-created local users.
• On hit, mutate the row in place: new token string, refreshed validation timestamps, rebind user to the current local user, clear deletedAt. Never create a second row — the unique constraint forbids it and the semantic intent ("one current token per Moodle user") is preserved.
• Defensive precondition: throw if user.moodleUserId is missing, mirroring MoodleToken.Create.

Adds repo-level unit tests covering: first-login, validation refresh (same token re-presented), rotated token (the failing case), and soft-deleted row revival.