V1.4.10: 修复广告过滤失效（gz.ac16.vip 广告被当成歌曲下载播放）

现场事故（新设备 SM-S9180 / Android 16，WebView 正常 → 走 JS 取址）:
  277  JS [KtvApi] URL OK: 7303235 ls=1 via http://w.w345.my
  278  点歌编号=7303235 标题=情歌(HD) 请求源=http://w.w345.my 状态=成功 urlHost=gz.ac16.vip
  279  PLAY id=7303235 title=情歌(HD) src=local
即 gz.ac16.vip 的广告视频被当成歌曲下载、缓存并播放。

三处漏洞叠加:
1. ktv_api.js 的 isDemoUrl 不认识广告域名；且"ts 文件名与编号比对"用的是
   /\/(\d+)\.ts/，只匹配纯数字名 —— my_ad_video.ts 这类非数字名字直接放行；
2. SongOkDownloadManager.buildDownloadUrl 的**成功分支完全没有广告校验**
   （AdVideoFilter.isAdVideo 全项目只在"缓存地址"与"原生解析"两处被调用）；
3. SongApiClient.fetchFromDb 只做 isLikelyDemoUrl（纯 IP / r2.dev），挡不住广告域名。
且**内容校验挡不住广告**: 该广告通过 SongFileValidator（≥6MB/≥60s/TS 包完整），
被 isDownloaded() 一直复用，广告会反复播。

修复（单一闸门，全链路把关）:
- AdVideoFilter 新增 isTrustedSongUrl(url, musicno)：非 http(s)、命中广告特征
  （路径 /ad_files/、my_ad_video、**域名 *.ac16.vip**）、或 URL 里 .ts 文件名不等于
  点歌编号 → 一律不可信。真源恒为 /<musicno>.ts（已实测 txog.ktvsky.com 与
  download.origjoy.com 两个 CDN 域共 6 首全部相符）。
- 该闸门接入全部出入口: JS isDemoUrl（同步加固 + KTV_BRIDGE_API 8→9）、
  SongUrlResolver.isValidSongUrl、SongApiClient.fetchFromDb、
  以及最终兜底 SongOkDownloadManager.buildDownloadUrl（成功/缓存两条分支）。
- 判定不可信时**同时删除已落盘的歌曲文件**（purgeCachedSongFile），
  否则 isDownloaded() 会一直复用那个广告文件。
- 新增 SongOkDownloadManager.purgeLegacySongCacheOnce(): 升级后一次性清理历史遗留的
  可疑歌曲缓存（marker: filesDir/song_cache_purged_v1）。只是让歌曲重新下载，不动用户数据。
- 新增回归测试 AdVideoFilterTest（6 例，用日志里的真实 URL 形态，含两个真源 CDN 域）；
  该测试当场抓到本修复自身的一个 bug：正则把扩展名也捕获进去导致真源被误杀，已修正。

版本 1.4.9(29) 到 1.4.10(30)；签名证书不变。

AGENTS.md

@@ -160,7 +160,7 @@ $BT/apksigner verify 目标名.apk
 
 ### 版本号
 
-- `app/build.gradle`：`versionName "1.4.9"` / `versionCode 29`（18~21 被本机临时诊断包占用过）
+- `app/build.gradle`：`versionName "1.4.10"` / `versionCode 30`（18~21 被本机临时诊断包占用过）
 - App 内显示统一用纯版本号（不加 `(versionCode)` 括号）
 - ⚠️ **发布构建已开启 NewApi 闸门**（`lint { checkReleaseBuilds true; fatal += ['NewApi'] }`）：
   任何「调用了高于 `minSdk 21` 且未做版本守卫的 API」都会让 `assembleRelease` 直接失败。
@@ -273,6 +273,24 @@ $BT/apksigner verify 目标名.apk
     `NATIVE-SONG 全部源失败 编号=... 详情=token-fail|no-url|demo-or-mismatch`；
     桥侧另有 `JS-BRIDGE ...`（ready / KtvApi 未导出 / WebView 初始化失败 / 15s 未就绪）。
 - **JS 热更新**：改动 `ktv_api.js` 必须同步提升 `KTV_BRIDGE_API: N` 标记（JS 与 `KtvJsBridge.kt` 两处校验），否则设备仍用缓存旧脚本
+- **⚠️ 广告/错号地址只有一道闸门：`AdVideoFilter.isTrustedSongUrl(url, musicno)`**
+  （2026-09-26 事故：新设备点歌 7303235 拿到 `gz.ac16.vip` 的**广告视频并被当成歌曲下载播放**）。
+  约定：
+  1. **任何来源**的播放地址都必须过这道闸门 —— JS 取址（`ktv_api.js` 的 `isDemoUrl`）、
+     原生兜底（`SongUrlResolver.isValidSongUrl`）、DB 回退（`SongApiClient.fetchFromDb`），
+     以及**最终兜底** `SongOkDownloadManager.buildDownloadUrl` 的成功分支。
+     只加在某一层必然漏：这次就是 JS 层的规则不认广告域名、且 Kotlin 的成功分支**完全没做校验**；
+  2. 判定三条：非 http(s)；命中广告特征（路径 `/ad_files/`、`my_ad_video`、**域名 `*.ac16.vip`**）；
+     **URL 里的 `.ts` 文件名必须等于点歌编号**（真源恒为 `/<musicno>.ts`，已实测
+     `txog.ktvsky.com` / `download.origjoy.com` 两个 CDN 域）。旧规则只比对"纯数字文件名"，
+     `my_ad_video.ts` 这类非数字名字直接漏过；
+  3. **内容校验挡不住广告**：广告视频能通过 `SongFileValidator`（≥6MB / ≥60s / TS 包完整），
+     所以"取址即校验"是唯一有效防线。一旦判定地址不可信，必须**同时删除已落盘的歌曲文件**
+     （`purgeCachedSongFile`），否则 `isDownloaded()` 会一直复用那个广告文件，广告反复播；
+  4. 历史遗留由 `SongOkDownloadManager.purgeLegacySongCacheOnce()` 在升级后清一次
+     （marker：`filesDir/song_cache_purged_v1`）。清掉只是让歌曲重新下载，不影响用户数据；
+  5. 回归测试 `app/src/test/java/com/local/ktv/AdVideoFilterTest.java` 用日志里的**真实 URL 形态**
+     锁住行为（含两个真源 CDN 域），改这块逻辑必须先让它通过。
 - **曲库**：只走官方 Muse 同步（`MuseDbSync`），不再依赖代码仓库数据库文件
 - **曲库同步时效**：默认 **30 天**（`DatabaseBootstrapper.SYNC_TTL_DAYS`）。未到期启动**不联网**、直接用本地曲库；到期后才查询服务器版本，有更新才下载。时效起点记录在 `db_sync_at.txt`，由 `DatabaseBootstrapper.markSynced()` 写入（下载成功或校验为最新时）。设置页「曲库 → 更新」为手动强制检查（绕过时效，仅在服务器版本更新时下载）
 - **麦克风**：`MicActivator` 常驻占用输入通道（TV/投影需占用后才有演唱声音输出），外接设备热插拔会自动重建