fix(auth): self-healing displayName; drop synthetic Member<sub> from storage

The legend showed 'Member 972be1a3' because Authelia does not emit
name/preferred_username/email in the ID TOKEN (only at the userinfo endpoint),
and @hono/oidc-auth reads ID-token claims only. The real fix is an Authelia
claims_policy adding those claims to id_token for the familysync client.

App-side robustness so it self-heals once Authelia is fixed (no DB surgery):
- deriveDisplayName now returns null (not a synthetic 'Member <sub>') when no
  real claim is present, so we never persist an ugly sub string; the UI degrades
  to a generic 'Member'.
- upsertUser now tracks the IdP name authoritatively: a non-null displayName that
  differs from the stored value updates the row (blank/stale 'Member …'/email →
  real name on next login). A null value never overwrites a good stored name.

apps/api/src/routes/me.ts

@@ -56,7 +56,7 @@ meRouter.get('/', async (c) => {
   // Derive the best available display name from OIDC claims (name →
   // preferred_username → email → sub fallback). Shared helper keeps every
   // upsert call site in agreement (see deriveDisplayName).
-  const displayName = deriveDisplayName(auth, sub)
+  const displayName = deriveDisplayName(auth)
 
   const user = await upsertUser(iss, sub, displayName)