feat(分组权限): 业务分组模型 + DataScope 判定 + 列表接口接入

第一阶段：模型 → 判定 → /auth/me → 列表。统计接口与前端管理页随后。

1) 模型与迁移（head 从 k1l2m3n4o5p6 推进到 l1m2n3o4p5q6）
   · business_groups        组定义，parent_id 表达「大组 > 小组」
   · business_group_phases  可见范围，独立成表以支持多选 —— 需求要求
                            「范围可配置、不要写死」，单列存不下多个 phase
   · business_group_members 成员，一人可属多组（这是「同时看生产+维修」的实现）
   只建表、不写种子数据，所以可以先部署代码再建组。

2) DataScope 判定模块（app/services/data_scope_service.py）
   全仓库唯一的权限谓词来源，业务代码里不准再出现 lifecycle_phase 过滤。
   两条红线照抄部门隔离的教训：
   · None(不限) 与 frozenset()(空) 语义相反，绝不共用一个哨兵值
   · 空集合必须显式 false() —— SQLAlchemy 对 in_(()) 生 成 IN (NULL)，
     一旦退化成不过滤就是全量泄漏
   解析优先级：SUPER_ADMIN 硬放行（不可被分组覆盖）
             > 显式分组（分组优先于角色）
             > 未分组 SUPERVISOR 默认全厂
             > 未分组普通用户

3) 过渡期开关 DATA_SCOPE_UNGROUPED（默认 ALL）
   直接上严格模式会让所有未分组工人当场看不到自己的任务、现场停摆。
   默认 ALL 先放行并打 WARNING 记录「谁还没分组」，配好组后再改 NONE。

4) /auth/me 返回 scope，phase 中文标签由服务端下发
   —— 前端已有两份 phase 词表副本，不再加第三份。

5) 列表接口接入
   · get_all_products：过滤加在 offset/limit 之前（其下有 6 段基于 product_ids
     的批量预计算，过滤晚了等于算完再丢）
   · get_all_tasks：谓词进【共享 filters】，保证 count 与 select 两条独立语句
     同时生效，否则 total 与实际页不一致、移动端 hasMore 判断跟着错
   · 扫码 get_product_by_serial 刻意不过滤，理由写死在 docstring 里

实测：空 scope 生成 false、受限 scope 生成 JOIN + IN 谓词；
/products 返回 2 条、/tasks 的 total 与 returned 一致。

backend/app/services/product_service.py

@@ -19,6 +19,8 @@ from app.models.production_order import ProductionOrder
 from app.models.task import Task
 from app.schemas.product import ProductCreate, ProductUpdate, ProductResponse, ProductScanResponse
 from app.schemas.task import TaskSummaryResponse, TaskResponse, TaskRecordResponse
+# 业务分组数据范围 —— 只借用类型，谓词一律由 DataScope 生成，不在这里手写 IN 条件
+from app.services.data_scope_service import DataScope
 
 
 def _task_to_response(task: Task) -> TaskResponse:
@@ -62,7 +64,21 @@ async def _load_task_tree(db: AsyncSession, product_id: uuid.UUID) -> list[TaskR
 
 
 async def get_product_by_serial(db: AsyncSession, serial_number: str) -> ProductScanResponse:
-    """扫码查询：根据 16 位序列号查出产品 + 所属订单 + 完整任务树"""
+    """扫码查询：根据 16 位序列号查出产品 + 所属订单 + 完整任务树。
+
+    ⚠️ 本函数**刻意不接受 DataScope、也不做业务分组过滤** —— 这是与
+       「列表按组过滤」同等重要的设计决策，不是漏改：
+
+       · 维修组扫到一台生产中的设备必须能【看】。现场要判断的恰恰是
+         「这台机器是不是走错了流程 / 该不该到我这儿」，看不见就无法判断。
+       · 「不能操作」由操作类接口各自的属主校验（task_service._check_permission）
+         保证，不在查询层做。
+       · 在这里加范围过滤会让维修工扫自己的设备都可能 404 —— 功能性倒退。
+       · 本函数另有 3 个内部调用点（product_finalize_service 两处、
+         product_service 内部一处），加必传参数会波及它们。
+
+       如需调整这个决策，请先跟业务确认「跨组扫码要能看」这条是否仍然成立。
+    """
     result = await db.execute(
         select(Product)
         .options(
@@ -524,6 +540,7 @@ def _lookup_display_names(location_ids: list[str]) -> dict[str, str]:
 
 async def get_all_products(
     db: AsyncSession,
+    scope: DataScope,
     skip: int = 0,
     limit: int = 50,
     keyword: str | None = None,
@@ -534,6 +551,9 @@ async def get_all_products(
 
     keyword: 同时模糊匹配 serial_number (产品身份证)、material_name/id (规格型号)、order_no (订单号)
     status_filter: 按产品状态过滤 (如 PENDING / WIP / COMPLETED / ARCHIVED)
+
+    ⚠️ scope **不给默认值**：它是业务分组的权限边界，漏传必须当场 TypeError，
+       而不是悄悄退化成「不过滤」——那等于全量泄漏。
     """
     stmt = select(Product).options(selectinload(Product.order))
 
@@ -620,6 +640,14 @@ async def get_all_products(
             # 兜底：其他状态码按"存在该状态任务"匹配（未完结）
             stmt = stmt.where(not_finished, _has_task_status(sf))
 
+    # 🚀 业务分组数据范围过滤。
+    #    位置很关键：必须加在 offset/limit **之前**，因为下面有 6 段基于
+    #    product_ids 的批量预计算（macro_status / 最新任务 / 主干工序 / 滞留时长 /
+    #    生产天数），过滤晚了等于把这些算完再丢掉，纯浪费。
+    #    注：上面的 keyword 分支带了 .distinct()，在其后追加 .where() 语义正确
+    #    （distinct 是整体修饰，不是"立即去重"）。
+    stmt = stmt.where(scope.product_where())
+
     stmt = stmt.offset(skip).limit(limit).order_by(Product.created_at.desc())
 
     result = await db.execute(stmt)