fix(auth): use the guild OAuth app for header login on custom domains

[Musiker15]

Problem (customer report)

Customer configured their own per-guild Discord OAuth app (Client ID + secret, redirect URL) on their custom domain urlap.atlasroleplay.hu. Dashboard shows Active, but login still lands on the MSK Forms OAuth consent screen instead of the guild''s own app.

Root cause

The header "Log in" button builds its href from the absolute primary URL on custom domains:

const base = onCustomDomain ? appBaseUrl() : "";
const loginHref = `${base}/api/auth/discord/login`;

So clicking it on the custom domain goes straight to https://forms.msk-scripts.de/api/auth/discord/login → host = primary → global MSK Forms app. This was intentional before per-guild OAuth (#146) — the dashboard/state-cookie live on primary — but it bypasses the guild''s own app. The public form login link is already relative + host-aware and works; only the header was wrong.

Fix

• Header login is now host-aware: on a custom domain whose guild has its own OAuth app (resolveHostOAuth(host) != null), the login link is relative, so the host-aware login route uses the guild app and establishes the session on the custom domain. Without an own app it still points to primary (state cookie + callback must be same-origin). Dashboard link unchanged (primary-only).
• Diagnosability: the silent fallback to the primary app is now logged — both the generic "no per-guild OAuth for host" case and specifically when a stored secret is present but undecryptable (the dashboard marks "Active" on presence alone, so a broken secret was invisible).

Notes

No schema/env change. typecheck green. If the customer still lands on MSK Forms after this, the new [guild-oauth] … could not be decrypted / [oauth-login] no per-guild OAuth for host PM2 log lines will pinpoint whether it''s a bad secret or an unverified domain.