feat: prefer supabase jwt in taro api client

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

@@ -139,7 +139,7 @@ PLATFORM_ADMIN_API_KEY
 
 ## API 请求目标形态
 
-当前迁移期：
+历史迁移期接口曾允许：
 
 ```text
 Authorization: Bearer <tk_session>
@@ -147,13 +147,15 @@ x-tenant-id: <tenantId>
 x-user-id: <userId>
 ```
 
-生产目标：
+新的 Taro client 已经禁止页面使用 `x-user-id` 表示当前用户，并默认采用 Supabase JWT 优先：
 
 ```text
 Authorization: Bearer <supabase_access_token>
 x-tenant-id: <tenantId>   # 可选租户上下文；不是身份来源，必须与 JWT tenant claim 或 membership 匹配
 ```
 
+`apps/taro/src/services/api.ts` 的 `apiRequest` 默认 `authMode='auto'`：H5 优先发送 Supabase access token，没有 Supabase token 时才兜底迁移期 `tk_` session。公共接口必须显式使用 `authMode='none'`，迁移演练才允许使用 `authMode='legacy'`，云端正式回归可用 `authMode='supabase'` 强制暴露残留 legacy 依赖。`headers.Authorization` 和 `headers['x-tenant-id']` 是保留 header，页面代码不能覆盖。
+
 当前 `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`，后端会校验该用户确实属于该租户。
 
 生产时后端负责：
@@ -183,6 +185,7 @@ ALLOW_PLATFORM_ADMIN_KEY=false
 - 不要把 Supabase-first 误解成前端直写所有表。
 - 不要让 Taro 直接写订单、支付、权益、租户配置、CRM、导入相关表。
 - 不要把 service role/secret key 放进 Taro。
+- 不要在页面里绕过 `apiRequest` 手写 `Taro.request`、`Authorization`、`x-tenant-id` 或 `x-user-id`。
 - 不要为了少写接口而放宽 RLS。
 - 新增前端直连 Supabase table/view/RPC 之前，必须先补：
   - 明确 RLS policy。