feat: add supabase jwt auth context

docs/refactor/supabase-frontend-access-strategy.md

@@ -147,20 +147,34 @@ x-user-id: <userId>
 生产目标：
 
 ```text
-Authorization: Bearer <supabase_access_token_or_server_session>
+Authorization: Bearer <supabase_access_token>
+x-tenant-id: <tenantId>   # 可选租户上下文；不是身份来源，必须与 JWT tenant claim 或 membership 匹配
 ```
 
+当前 `apps/api` 已支持 Supabase Auth JWT 验签，并通过 `auth.users.id -> platform_users.auth_user_id -> tenant_memberships` 映射到业务身份。H5/Taro 登录后可以直接把 Supabase access token 放到 `Authorization`。如果 JWT 内没有 `tenant_id` claim，前端仍要根据域名/小程序码解析后的租户传 `x-tenant-id`，后端会校验该用户确实属于该租户。
+
 生产时后端负责：
 
 - 验证 JWT。
-- 从 JWT/session 获取 userId。
-- 根据 host/tenantCode/JWT claims 解析 tenant。
+- 从 JWT 映射业务 userId。
+- 根据 host/tenantCode/JWT claims/请求上下文解析 tenant。
 - 校验用户属于该租户。
 - 校验角色和权限。
 - 执行业务逻辑。
 
 前端不再传 `x-user-id`，也不能靠传 `tenantId` 获得跨租户数据。
 
+生产 API 环境变量至少要配置：
+
+```text
+AUTH_JWT_JWKS_URL=https://<supabase-auth-host>/auth/v1/.well-known/jwks.json
+# 或自托管/兼容模式下使用强随机 secret
+AUTH_JWT_SECRET=<strong-jwt-secret>
+AUTH_JWT_AUDIENCE=authenticated
+ALLOW_LEGACY_AUTH_HEADERS=false
+ALLOW_PLATFORM_ADMIN_KEY=false
+```
+
 ## 对后续 AI/开发者的硬性约束
 
 - 不要把 Supabase-first 误解成前端直写所有表。