feat: add supabase jwt auth context

docs/refactor/multitenant-auth-security-contract.md

@@ -20,6 +20,9 @@
 当前后端已经进入“session 优先、迁移头受控兼容”的状态：
 
 - `Authorization: Bearer <tk_session>` 会优先解析 `app_private.auth_sessions`，并作为用户身份来源。
+- `Authorization: Bearer <supabase_access_token>` 已支持服务端验签，后端通过 `auth.users.id -> platform_users.auth_user_id -> tenant_memberships` 映射到业务用户和租户成员。
+- Supabase JWT 支持 `AUTH_JWT_SECRET` 或 `AUTH_JWT_JWKS_URL`；生产推荐优先配置 Supabase Auth JWKS，或在自托管兼容模式下配置强随机 JWT secret。
+- JWT 可以在 `app_metadata.tenant_id` 或请求租户上下文中确定当前租户；如果两者冲突，后端拒绝，不允许前端覆盖 token 中的租户声明。
 - 登录后如果请求中的 `x-user-id`、query/body `userId` 与 session 用户不一致，后端返回 `AUTH_USER_MISMATCH`。
 - 登录后如果请求中的 `x-tenant-id` 与 session 租户不一致，后端返回 `AUTH_TENANT_MISMATCH`。
 - 带了无效 bearer token 的用户态接口不会回退到 `x-user-id`。
@@ -37,10 +40,10 @@ Supabase 官方允许前端用 Data API 访问数据，但前提是 RLS、最小
 ## P0：正式云端测试前必须完成
 
 1. 正式用户鉴权
-   - 已支持服务端 session 解析可信 userId。
-   - 生产前继续接 Supabase Auth/JWT，或将现有 server session 明确作为正式方案。
+   - 已支持服务端 session 和 Supabase Auth JWT 解析可信 userId。
+   - 生产前必须用真实 Supabase Auth 项目或自托管 Auth 实例跑一轮云端 JWT 回归。
    - 前端禁止通过 query/body/header 指定 userId。
-   - `GET /api/auth/me` 后续要补租户成员、角色、权限返回。
+   - `GET /api/auth/me` 已支持 Supabase JWT；后续要补租户成员、角色、权限返回。
 
 2. 正式租户上下文
    - H5 可由域名解析租户。
@@ -50,12 +53,13 @@ Supabase 官方允许前端用 Data API 访问数据，但前提是 RLS、最小
 
 3. 平台管理员鉴权
    - `x-platform-admin-key` 已可通过 `ALLOW_PLATFORM_ADMIN_KEY=false` 禁用。
-   - 生产前仍需替换为平台管理员 JWT/session 和审计日志。
-   - 平台管理员也要有 JWT/session、角色、审计日志。
+   - 已支持平台管理员 Supabase JWT，且以后端 `platform_users.primary_role='platform_admin'` 为准，不只信 JWT claim。
+   - 生产前继续补平台后台关键操作审计报表和更细权限点。
 
 4. 生产配置 fail-fast
    - `NODE_ENV=production` 时禁止默认 `AUTH_CODE_PEPPER`。
    - 禁止默认 `AUTH_SESSION_SECRET`。
+   - 禁止默认 `AUTH_JWT_SECRET`，除非配置了 `AUTH_JWT_JWKS_URL`。
    - 禁止默认 `PLATFORM_ADMIN_API_KEY`。
    - 禁止 `CORS_ORIGIN=*`。
    - 禁止 `AUTH_SMS_PROVIDER=mock`。