refactor(backend)!: separate algorithm and data layers

Reorganize algorithm packages by business responsibility, move orchestration into services, and keep database access behind pooled repositories.

Harden analysis API validation, remove unsafe legacy simulation endpoints, and add regression and architecture boundary coverage.

BREAKING CHANGE: legacy algorithm module paths and obsolete simulation endpoints are removed.

resources/db_v2/WNDB_STRUCTURE.md

@@ -135,12 +135,12 @@ flowchart LR
 
 | 职责 | 当前路径 | 原因 |
 | --- | --- | --- |
-| 用水量分配计算 | `app/algorithms/water_demand/` | 属于业务算法，WNDB 只提供节点、需求和区域查询 |
-| SCADA 资产查询 | `app/infra/db/postgresql/scada_assets.py` | 对应 `asset.scada_devices` 的 PostgreSQL 仓储 |
+| 用水量分配计算 | `app/algorithms/demand_allocation/` | 只接收普通拓扑数据；数据库装载位于 `app/services/demand_allocation.py` |
+| SCADA 资产查询 | `app/infra/db/postgresql/scada.py` | 对应 `asset.scada_devices` 的 PostgreSQL 仓储 |
 | 测压点选址结果 | `app/infra/db/postgresql/sensor_placement.py` | 对应 `analysis.runs` 和 `analysis.results` 的仓储 |
-| 服务组合入口 | `app/services/tjnetwork.py` | 组合 WNDB、EPANET 和业务仓储，供接口与算法层调用 |
+| 网络 API 门面 | `app/services/tjnetwork.py` | 暂时组合 WNDB 与 EPANET 供 HTTP 接口调用；算法层不再依赖该门面 |
 
-`tjnetwork.py` 从约 995 行缩减到约 320 行。它不再通过 WNDB 根包获得全部函数，只显式导入当前服务使用的能力。过时的 `scripts/test_tjnetwork.py` 依赖已移除的 operation、snapshot、DMA 和旧 SCADA API，已经一并删除。
+`tjnetwork.py` 从约 995 行缩减到约 285 行。它不再通过 WNDB 根包获得全部函数，只显式导入当前接口使用的能力。过时的 `scripts/test_tjnetwork.py` 依赖已移除的 operation、snapshot、DMA 和旧 SCADA API，已经一并删除。
 
 ### HTTP 执行边界
 
@@ -152,8 +152,8 @@ WNDB 当前使用同步 `psycopg` 连接池。`network/`、`components/` 和同
 
 ```mermaid
 flowchart TD
-    API[HTTP 接口与业务服务]
-    SERVICE[services.tjnetwork]
+    API[HTTP 接口]
+    SERVICE[应用服务]
     ALGORITHM[业务算法]
     REPOSITORY[PostgreSQL 业务仓储]
     COMMANDS[wndb.commands]
@@ -164,8 +164,8 @@ flowchart TD
     DB[(项目业务数据库)]
 
     API --> SERVICE
-    API --> ALGORITHM
     API --> REPOSITORY
+    SERVICE --> ALGORITHM
     SERVICE --> COMMANDS
     SERVICE --> INP
     SERVICE --> MODEL
@@ -187,13 +187,15 @@ flowchart TD
 
 WNDB 根包不再作为依赖汇聚点。上层若只需要管道查询，应直接依赖 `model.pipes`；需要区域几何时依赖 `gis.region_geometry`；需要项目连接时依赖 `core.connection`。
 
+`app/algorithms` 已按业务能力改为 `burst_detection`、`burst_localization`、`scada_cleaning`、`pipe_health_prediction`、`valve_isolation`、`dma_leakage_estimation`、`pressure_sensor_placement` 和 `demand_allocation`。自动化架构测试禁止算法层反向依赖 service、infra、native 或 API，也禁止 infra 依赖 service/algorithm。少量只做仓储转发的 HTTP 接口仍直接依赖 repository，后续按业务聚合需要迁入应用服务，不为机械包装而增加空壳层。
+
 ## 仍需留意的文件规模
 
 `importer.py` 和 `region_geometry.py` 行数较多，但函数仍围绕单一职责。只有在继续增加 INP 格式或区域算法时，才需要分别拆出版本转换器或边界算法模块。目前没有必要为了控制文件行数继续分层。
 
 ## 验证结果
 
-- 本地 conda 环境单元、鉴权和 API 测试：286 项通过，2 项按条件跳过。
+- 本地 conda 环境单元、鉴权和 API 测试：313 项通过，2 项按条件跳过。
 - 一次性实库从 `tjwater_v2_template` 创建后，通过 INP 暂存解析和事务替换得到 11 个节点、13 条连接、11 条坐标及 9 条 junction 物化视图记录，验证后已完整删除。
 - `tjwater_v2` 统一视图覆盖 87,907 个节点和 91,054 条链路，与六个来源物化视图的合计数量一致。实测完整节点读取约 0.17 秒、完整链路读取约 0.10 秒、完整拓扑两次批量查询约 1.12 秒；耗时仅作为当前环境基线，不作为固定性能承诺。
 - `tjwater_v2` 真实数据库测试：11 项通过，覆盖业务库和时序库并发借用、失效连接自动重建、临时库模型/SCADA/视图完整克隆与清理、嵌套事务回滚、分析运行生命周期、恶意标识符转义、明细表复合主键、统一 GIS 查询视图，以及 WNDB pattern 增删改、级联解除需求关联和整体回滚。