取址改为官方源优先+自建源兜底，只有官方源成功才上报（V1.6.2/45，未发布）

需求一：流程反转 + 上报绑定官方源成功
- 默认 sourceHosts 反转为 ["http://zk.ktv1.top:6677", "https://mdmuse.kasugano.cn"]；
  SourceHosts.DEFAULT / SongUrlResolver.DEFAULT_HOSTS（收敛为引用前者）/ ktv_api.js
  CONFIG.HOSTS+HOST 三处一致。
- 取址结果改为 SourcedSongUrl(url, sourceHost)（**显式来源标志**，不靠 URL 猜）：
  新增 SongSourceFlow（回落链 firstAvailable / 上报判定 shouldReportToSelfHost /
  全失败信号）；JS 侧新增 android.onSongSource(requestId, host) 回传命中的源。
- 汇合点 SongApiClient.getSongDownloadUrl 只在"地址来自官方源"时才 POST /push_download；
  自建源自己给的地址与 DB 回落都不上报。
- 推送默认目标改为"从歌曲源列表里找第一个自建源"（自建源不再排第一，旧写法会直接关掉推送）。
- 1.6.1 落盘的旧默认顺序（自建源优先）在 KtvStore.load() 里一次性迁移；自定义列表不动。
- 业务码 404（自建源没有这首歌）仍只当"该源没地址"，不置 sawForbidden、不进冷却、不污染受限统计。

需求二：6 条隐患
1) 设置页改源对 JS 立即生效：KtvJsBridge.applySourceSettingsNow 重新注入 KtvApiConfig.*
   并把已构造实例的 window.api.sourceOrder 重置为新列表；SongApiClient.applySourceSettings 接线。
2) JS 路径识别业务码 403：新增 KtvJsBridge.riskForbidden(status, body)（纯函数，手写判定
   避免 org.json 在单测里是空壳），HTTP 403 与 HTTP 200+{"code":403} 都算风控，与原生 sawForbidden 同口径。
3) isTrustedDownloadUrl 移除广告域名 ac16.vip 白名单，并改为黑名单优先（不再依赖调用顺序）。
4) MainActivity.download(song)（第五条地址消费点）补 AdVideoFilter.isTrustedSongUrl 闸门，
   不可信按"源失效"处理（Eac19WindowGuard.noteAllSourcesFailed），不再静默下载。
5) SongApiClient.fetchFromDb 不再静默吞异常：曲库打不开/查询异常各记一条 MiliLog.localWarn（含编号与异常）。
6) 删除死代码 streamDownloadAndPlay（全仓 grep 无调用点，且内部取址不过最终闸门）。

需求三：死代码/漂移清理（均先全仓搜索确认无引用）
- AdVideoFilter.replacementUrl 无任何写入点（恒为 null）→ 删除，resolve() 只保留"屏蔽"语义。
- ktv_api.js CONFIG.VER/VN 由"从不生效的死值"改为实际使用值 2.0 / 4.1.3.03281430。
- CONFIG.HOST 改为被 getToken 真正读取（不再"注入但从未被读"）。
- KTV_BRIDGE_API 14 → 15（JS 两处 + KtvJsBridge 两处校验）；AGENTS.md / README.md / README.en.md
  的陈旧标记统一到 15。
- do.php 的 limit 与 i.php 的 retry/ordertype/end_date/heart_time 确认无消费方 → 不新增解析（保持现状）。

需求四：测试与打包
- 新增 SourceOrderConsistencyTest / SongSourceFlowTest / JsBridgeGateTest / DownloadEntryGateTest，
  更新 SourceHostsTest / AdVideoFilterTest；app/build.gradle 打开 unitTests.returnDefaultValues。
- testReleaseUnitTest --rerun-tasks --offline：12 个测试类 / 87 例全过。
- assembleRelease --offline 通过（lintVital NewApi 0 条）；版本 1.6.1/44 → 1.6.2/45。

不发布：未推 Gitea/Gitee、未动 Release/tag。

AGENTS.md

@@ -195,8 +195,10 @@ $BT/apksigner verify 目标名.apk
 
 ### 版本号
 
-- `app/build.gradle`：`versionName "1.6.0"` / `versionCode 43`
-  （`1.5.5`/`37` 已发布；`1.5.6` = 更新源加 Gitee、`1.5.7` = 删除「歌曲源临时受限」弹窗、`1.5.8` = 精简远程日志、`1.5.9` = 按 HAR 对齐原版协议、`1.5.10` = 源列表只留 zk.ktv1.top:6677、`1.5.11`(命名越界,已改) / `1.6.0` = whoami 心跳/设备身份/点歌推送/带 query 的地址闸门 + 并入 selfhost-source 支线，均尚未发布。18~21 曾被本机临时诊断包占用）
+- `app/build.gradle`：`versionName "1.6.2"` / `versionCode 45`
+  （`1.5.5`/`37` 已发布；`1.5.6` = 更新源加 Gitee、`1.5.7` = 删除「歌曲源临时受限」弹窗、`1.5.8` = 精简远程日志、`1.5.9` = 按 HAR 对齐原版协议、`1.5.10` = 源列表只留 zk.ktv1.top:6677、`1.5.11`(命名越界,已改) / `1.6.0` = whoami 心跳/设备身份/点歌推送/带 query 的地址闸门 + 并入 selfhost-source 支线、
+  `1.6.1`/`44` = App 接入自建源（自建源优先 / App 令牌 / 媒体允许清单 / 推送默认目标）、
+  `1.6.2`/`45` = **取址反转成"官方源优先、自建源兜底" + 只有官方源成功才上报**（含 6 条隐患修复与死代码清理），以上 1.5.6~1.6.2 均尚未发布。18~21 曾被本机临时诊断包占用）
 - App 内显示统一用纯版本号（不加 `(versionCode)` 括号）
 - ⚠️ **本机 `/tmp` 是 tmpfs，单测必须绕开它**：`/tmp`（5.6G tmpfs）长期被"已删除但仍被打开"的
   文件占满，单测写临时文件会抛 `IOException: 超出磁盘配额`（EDQUOT），**看起来像测试失败**。
@@ -331,6 +333,27 @@ $BT/apksigner verify 目标名.apk
     裸 socket 会正确使用 `uri.port`（6677）—— 以前只有域名源，改这块要注意别丢端口。
   - `AdVideoFilter.AD_HOSTS`（媒体层广告域名黑名单）**不变**：它管的是"返回地址"的 host，
     与"取址入口"无关（见上文判定原则）。
+- **⚠️ 取址改为「官方源优先、自建源兜底」+ 只有官方源成功才上报（2026-10-14）**：
+  `SourceHosts.DEFAULT` = `["http://zk.ktv1.top:6677", "https://mdmuse.kasugano.cn"]`
+  （**官方源第一、自建源兜底**；与上一版"自建源优先"正好相反）。
+  1. **三处一致**：`ktv_api.js` 的 `CONFIG.HOSTS`/`CONFIG.HOST`、`SongUrlResolver.DEFAULT_HOSTS`
+     （**已收敛为引用 `SourceHosts.DEFAULT`，不再各写一份字面量**）、`SourceHosts.DEFAULT`；
+     由 `SourceOrderConsistencyTest` 与 `tools/check_source_hosts.py` 双保险锁住。
+  2. **上报绑定"官方源成功"**：只有地址来自官方源才 `POST /push_download` 给自建服务器
+     （自建源自己给的地址**不上报**）。判断靠取址实现**显式返回的来源标志**
+     （`SourcedSongUrl.sourceHost` → `SourceHosts.isOfficialSource`），
+     在汇合点 `SongApiClient.getSongDownloadUrl` 用 `SongSourceFlow.shouldReportToSelfHost` 一处判定；
+     **不要**靠 URL 字符串猜、也不要读 `lastHost` 这类可变全局。
+  3. **推送默认目标**：`pushServerUrl` 留空时从 `sourceHosts` 里找**第一个自建源**
+     （自建源不再排第一，旧写法只看 `first` 会直接把推送关掉）。
+  4. **旧默认值迁移**：1.6.1（已打包、未发布）落盘的"自建源优先"顺序在 `KtvStore.load()` 里
+     迁移成新默认（`SourceHosts.migrateLegacyDefault`，**只有恰好等于旧默认才迁移**，
+     用户自定义列表一律不动）。
+  5. **"自建源没有这首歌"（业务码 404）不是风控**：不置 `sawForbidden`、不进冷却、不污染受限统计；
+     风控只认 HTTP 403 与 **HTTP 200 + 业务码 403**（`KtvJsBridge.riskForbidden` 与
+     `SongUrlResolver.sawForbidden` 同口径）。
+  6. `KTV_BRIDGE_API` 由 14 → **15**（`ktv_api.js` 两处 + `KtvJsBridge` 两处校验；
+     本次同时把 JS 的取址结果用 `android.onSongSource(requestId, host)` 带回命中的源）。
 - **⚠️ 原版协议对齐（2026-10-08，依据 HAR 抓包实测）**：抓包（Reqable，`e.ac19.cn`）显示原版客户端是**三步**：
   1. **`POST /api.php`**：`Content-Type: application/x-www-form-urlencoded`，
      body `action=get_config&device_id=<mac>`，UA
@@ -398,7 +421,7 @@ $BT/apksigner verify 目标名.apk
      旧实现在 `#fragment` 上会**整条文件名规则失效（漏放广告）**，拿整串搜 `wb66`/`demo`
      又会误杀 query 里的签名串（"地址不可信"的隐蔽来源）。裸 IP / `pub-*.r2.dev/ss/`
      也已收进这道闸门 —— 四条路径不再各判一套。JS 侧同步改（`splitUrl()`），
-     `KTV_BRIDGE_API` 已升到 **13**；回归用例见 `AdVideoFilterTest`（带 query/fragment 的
+     `KTV_BRIDGE_API` 已升到 **15**；回归用例见 `AdVideoFilterTest`（带 query/fragment 的
      真源放行、广告仍拒）与服务端 `tests/test_basic.py::TestQueryStringGate`；
   3. **内容校验挡不住广告**：广告视频能通过 `SongFileValidator`（≥6MB / ≥60s / TS 包完整），
      所以"取址即校验"是唯一有效防线。一旦判定地址不可信，必须**同时删除已落盘的歌曲文件**
@@ -652,8 +675,10 @@ $BT/apksigner verify 目标名.apk
   唯一例外是"马上要 `play()` 下一首"的路径（可以不停，避免切歌瞬间静音）。
 - **⚠️ 「切歌 → 公放」在老盒子上卡死（2026-09-26，极米 H1S）**：新设备正常、老设备卡死，
   排查出**三个叠加原因**，都已修掉，改动这块时必须同时守住：
-  1. **不能共用 `io` 线程池**：`io` 只有 4 个线程，且"点歌即下即播"（`streamDownloadAndPlay`）
-     这类几十秒的长任务也在里面。老设备网速慢，并发点几首歌就把池占满，切歌任务一直排队。
+  1. **不能共用 `io` 线程池**：`io` 只有 4 个线程，且"点歌即下即播"（当时是 `streamDownloadAndPlay`，
+     该函数已作为死代码在 1.6.2 删除；现在这条链路是 `startDownloadAndPlay` → `downloadSong`
+     → `SongOkDownloadManager`）这类几十秒的长任务也在里面。老设备网速慢，并发点几首歌就把池占满，
+     切歌任务一直排队。
      → 切歌/随机续播改用 `randomPlayExecutor`（专用单线程守护线程）。
   2. **不能现扫目录找候选**：候选来自 `localSongInventory()` + `library.scanLocal()`，
      代价是"每个文件在头尾各读约 4.3MB 做 TS 校验" + "遍历 `/storage/ 各挂载点`