fix: enhance Entra identity linking and error handling in authentication

[Dinssa]

What

SSO sign-in returned a 500 for some users, with an unhandled IntegrityError.

Authentication.authenticate identified users solely by (entra_tid, entra_oid). Migration 0025 added those columns in June 2025 as nullable with no backfill, so every account created by the Entra flow before that date holds nulls in both while still owning its email and username. Those accounts miss the lookup permanently, so the code treated each sign-in as a new user and tried to insert a row whose username was already taken. An oid changing (account recreated in the tenant, guest converted to member) causes the same failure.

Changes:

• _find_user now tries three lookups in priority order: Entra identity, then email, then username (both case-insensitive). The first hit wins.
• A match writes the current entra_oid/entra_tid onto that account, so it is correctly identified from then on and matches on the identity lookup next time. Each affected account costs one extra pair of queries exactly once, which is why no backfill migration is needed.
• _is_tenant_allowed still runs first, so email matching only ever happens against an identity Microsoft has verified and an approved tenant.
• Any remaining IntegrityError is caught, reported to Sentry as a warning with the oid/tid in context, and the request is denied rather than 500ing. The message is static so the issue groups into one countable alert.
• The denial path now renders the existing templates/403.html instead of a bare text response. It links Knowledge Hub and the support desk, and says nothing about an account existing, so it does not leak whether an email is registered.

Ticket link

https://mhclgdigital.atlassian.net/browse/HFURB-2751

Checklist

• I double-checked that ACs on the ticket are met by this code update
• I have added tests to new code and updated existing tests where needed
• I have added testing instructions to the ticket
• I have added type hints to my new methods

Additional notes

Screenshots

[katstevens]

Doesn't HttpResponseForbidden default to using the 403.html template anyway?