Add GitHub account binding and a personal Sealos preview

[PeterGuy326]

Adds explicit GitHub connection status in profile settings and binds account linking to the user and browser session that started it. GitHub sign-in requires a verified primary email and uses state/PKCE; personal previews can restrict access by stable GitHub user ID. OAuth tokens are not retained.

Adds staged Sealos preview templates: initialize a fresh database, wait for completion, then start web and collaboration. Managed PostgreSQL includes monitoring views in an otherwise empty database. The opt-in guard accepts only eight confirmed views with exact extension membership and canonical definition/owner/dependency fingerprints matching the same server's template1; other relations and protected maintenance/template databases prevent initialization. Credentials stay in runtime Secrets. The preview supports text documents; uploads require separate OSS configuration.

Validation: the initial change passed 423 Vitest tests, 59 Linux CLI tests, production build, formatting/lint, collaboration checks, and three amd64 image builds. The current guard fix passed 23 focused tests, formatting, ESLint, syntax and diff checks. All current GitHub checks and three final image jobs passed for f7677ce8a1c53dd7b12d6a3474e0567654b8df55.

Live Sealos evidence: PostgreSQL 14.16 is Running/Ready. Fresh schema initialization completed with 13 business tables and all eight managed monitoring views preserved. Web and collaboration are Running/Ready with zero restarts, using immutable images copied byte-for-byte into a private regional registry. Public database health, sign-in SSR, GitHub-only provider, anonymous account/link denial, TLS WebSocket upgrade, and the exact GitHub callback with state/PKCE all passed.

Preview: doc. The region's actual domain is sealoshzh.site; GitHub homepage/callback and build-time browser URLs match it. Runtime and pull credentials were configured without printing values. Real GitHub authorization, authenticated document persistence and authenticated collaboration remain unverified; this PR remains a draft pending live acceptance.

[sun-970]

Reviewed from outside — no write access on this repository, so this is a comment, not an approval. The account-linking design is sound.

What I verified:

• PKCE + state checks are enabled on the GitHub provider, and signIn fails closed: an explicit but empty/malformed AUTH_GITHUB_ALLOWED_IDS returns false rather than silently opening the instance, and an unset allowlist only permits sign-in outside DOC_PERSONAL_PREVIEW.
• fetchVerifiedGitHubProfile uses GitHub's verified primary email, never the unverified public profile field, and validates id as a positive safe integer with redirect: 'error' and a timeout.
• The link intent is HMAC-signed with AUTH_SECRET and binds userId + a digest of the actual session cookie set; it is consumed one-time through a conditional deleteMany (expires > now()), compared with timingSafeEqual after a length check, and the cookie is deleted in signIn even on failure — so no replay.
• authSessionDigest correctly handles chunked authjs.session-token cookies and rejects malformed chunk sets instead of hashing a partial set.
• Changing jwt from trigger === 'signIn' to if (user?.id) and falling back to token.sub in session makes session.user.id reliable — a real fix, not just a rename.

Questions / nits:

1. In signIn, every non-GitHub provider (email/resend) returns process.env.DOC_PERSONAL_PREVIEW !== '1' — i.e. those providers are blocked when the personal preview flag is on. If that is intended, a one-line comment would stop it reading like an oversight.
2. issueGitHubLinkIntent inserts a verificationToken row per attempt and nothing sweeps expired ones; with repeated attempts they accumulate. The conditional consume keeps it correct, this is housekeeping only.
3. consumeGitHubLinkIntent relies on the DB clock for expires; fine, but worth stating in the PR body so a clock-skewed deploy is not mistaken for a signature bug.