✨ 小程序调度端运单列表、待处理与统计按组织收口

原先三个取数入口都不带组织条件，租户内两个组织的运单混在同一张表里。「小程序管理」
账号与运单业务组织不一致确实是事实，但那是账号挂在一个已软删部门上的脏数据症状，
不是「不该按组织过滤」的理由。

现在与后台运单列表同一条规则：普通用户只出自己所属组织，超级管理员不过滤，
小程序端不提供「全部组织」开关；详情与重新派单照旧不按组织收口。
组织条件由调用方算好、经 TripQueryVO.deptIds 落到运次读服务的运单行上，
列表、待处理与首页三档统计因此共用同一条可见范围；「待重新派单」另走库层分组查询，
单独带上，首页重派角标与待办 feed 随之一起收口。

运次读服务的分档统计走一份「去掉 Tab 条件」的副本，该副本必须照搬 deptIds，
否则统计会退回全租户、与列表的数对不上（已由用例钉住）。

存量 42 张 dept_id 为 -1 或 NULL 的运单不属于任何组织，收紧后普通用户再也看不到，
另订正到各自的创建组织，见 doc/sql/transport/blade_waybill_dept_backfill_20261018.sql。

新增 ManageWaybillOrgScopeTest（8 项），TripQueryServiceImplTest 补 3 项；
blade-transport 全量 376 项用例通过。

blade-service-api/blade-transport-api/src/main/java/org/springblade/transport/pojo/vo/TripQueryVO.java

@@ -53,6 +53,9 @@ public class TripQueryVO implements Serializable {
 	@Schema(description = "是否不按司机收口（管理端）")
 	private boolean allDrivers;
 
+	@Schema(description = "可见组织 ID 集合：非空时只出这些组织的运单行，空集合表示不按组织过滤")
+	private List<Long> deptIds;
+
 	@Schema(description = "状态：0待接单/1进行中/2已完成/3已取消，不传为全部（不含已取消）")
 	private Integer status;