fix(260607-l6l): derive displayName from OIDC claims in me.ts + resolveUserId

BUG 2: Both me.ts and events.ts resolveUserId were passing email (often
absent) as displayName to upsertUser, resulting in blank legend names.
Also, upsertUser returned existing rows unchanged even when displayName
was null and a better value was now available.

- me.ts: derive displayName via name → preferred_username → email →
  "Member <sub-prefix>" fallback, checked defensively. Updated JSDoc.
- events.ts resolveUserId: same derivation so write-path upserts don't
  re-blank a correctly-set displayName.
- user.ts: when existing row has null displayName and caller supplies one,
  issue an UPDATE so already-existing blank rows are corrected on next login.

Authelia-side emission of name/preferred_username is an operator concern
(claim mappings / userinfo scope in authelia config) — out of scope here.
The code now reads whatever claims are present and falls back sensibly.

apps/api/src/routes/events.ts

@@ -65,9 +65,19 @@ async function resolveUserId(c: any): Promise<number | null> {
 
   const iss = (auth.iss as string | undefined) ?? ''
   const sub = auth.sub ?? ''
-  const email = typeof auth.email === 'string' ? auth.email : undefined
 
-  const user = await upsertUser(iss, sub, email)
+  // Derive displayName with same preference order as me.ts (name → preferred_username
+  // → email → sub fallback). Both call sites must agree so a write-path upsert does not
+  // overwrite a correctly-derived name with a worse one.
+  const claimStr = (v: unknown): string | undefined =>
+    typeof v === 'string' && v.trim() !== '' ? v.trim() : undefined
+  const displayName =
+    claimStr(auth.name) ??
+    claimStr(auth.preferred_username) ??
+    claimStr(auth.email) ??
+    `Member ${String(sub).slice(0, 8)}`
+
+  const user = await upsertUser(iss, sub, displayName)
   return user?.id ?? null
 }