fix: 企业用户充电分析慢查询，改逆反查 + Service 层聚合（去跨分片 JOIN）

/order/t-charging-order/enterprise/charging/analysis 加载慢，无筛选时 MyCat 必超时，根因：
- 原 enterpriseChargingAnalysis 把 t_order_invoice(10片/app_user_id) +
  t_order_invoice_detail(20片/order_invoice_id) + t_charging_order(50片/app_user_id)
  在代理层跨分片 JOIN，分片键不一致只能全量广播，每次请求跑 3 遍
  （主聚合 + 前三站点 + 充电时间间隔，均重新扫描整条链路）
- mapper 带 IPage，分页拦截器生成无法下推的全量 COUNT（GROUP BY 外层）

修复（沿用 getRefundList / enterpriseChargingDetail 逆反查模式）：
- 去掉 IPage，改 Service 层手工分页
- 新增单表/按分片键 IN 路由的构建块：enterpriseInvoiceRows(单表) →
  enterpriseInvoiceDetailRows(order_invoice_id IN) →
  enterpriseAnalysisChargingOrders(id IN 走主键) → enterpriseAnalysisSites(id IN)
- 订单级筛选（站点/时间等）用 enterpriseAnalysisMatchingOrderIds 先筛命中订单，
  口径与 enterpriseChargingDetail 一致；按公司聚合在 Java 完成
- 语义保持：status IN (2,3)、order_type=1 明细、历史订单被删的发票仍计数、
  明细金额为 0 回退发票总金额、发票无命中订单时剔除

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>