fix: prevent duplicate moodle_token insert on Moodle token rotation

[y4nder]

Summary

Diagnosed via the new error-log admin page on staging — login for ucmn-t-67092 and harvie was 500'ing with:

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

`MoodleTokenRepository.UpsertFromMoodle` had two compounding issues:

1. Rotated-token branch created a duplicate row. When the incoming token string didn't match the stored one, the code kept the existing row alive (flipping `isValid = false`) and called `this.create(...)` to insert a second row with the same `moodleUserId`. The column-level UNIQUE constraint rejected the insert at flush time. Users whose token hadn't rotated hit the in-place-update branch and worked fine — which is why this only surfaced for some users.
2. Lookup was keyed by `user.id`, not `moodleUserId`. If the local `User` row was recreated with a fresh UUID, or the existing token was soft-deleted (hidden by the global filter), the find returned `null`, the create-path ran, and the unique constraint still saw the orphaned row.

Fix

• Look up by `moodleUserId` with `filters: { softDelete: false }` — resilient to rotated tokens, soft-deleted rows, and re-created local users.
• On hit, mutate in place: refresh `token` / `lastValidatedAt` / `isValid` / clear `invalidatedAt` and `deletedAt`, rebind `user` to the current local user. Never create a second row — semantic intent is "one current token per Moodle user", which matches the schema invariant.
• Defensive precondition: throw if `user.moodleUserId` is missing (mirrors `MoodleToken.Create`).

Test plan

• 6 new repo unit tests covering: first-login, validation refresh (same token re-presented), rotated token (the failing case), soft-deleted row revival, and the precondition guard
• Full suite green: `npm run test` — 1154 passing
• Lint clean on changed files
• After deploy: `ucmn-t-67092` and `harvie` log in cleanly; verify a fresh entry doesn't reappear on the `/error-logs` page
• Optional: check staging `moodle_token` for any orphan rows whose `user_id` no longer matches a live user — the fix will quietly reclaim them on next login, but a one-time audit is cheap

Related

• Diagnostics page that surfaced this: feat: error log admin diagnostics + multi-role dean login fix #397
• Earlier multi-role dean fix shipped in same PR (feat: error log admin diagnostics + multi-role dean login fix #397) addressed the next error in the chain (`resolveInstitutionalRoles`), so once this token-upsert fix lands, the full login path is clean.

🤖 Generated with Claude Code