fix(db): 流式缓存测试消除调度竞态，并将 Windows RDP 探针拆为独立 CI job - #233

execute_streaming_cancellable 通过 Tokio::spawn 把请求交给 Tokio 执行，并在
GPUI 后台执行器上等待其 JoinHandle。请求在 tokio worker 线程完成后会在该线程
唤醒这个 GPUI 后台任务，TestScheduler 将其判为
"Detected activity on thread tokio-rt-worker"，并在 end_test 处报错。这 5 个流式
缓存测试因此依赖真实 Tokio 的完成时序，在 CI 全量并行下偶发失败。

改为 #[tokio::test]，直接构造 StreamingExecutionRequest 在 Tokio runtime 上运行，
不再经过 GPUI 调度器；同时抽出 streaming_exec_opts 让生产路径与测试共用 options
归一化逻辑，避免测试镜像漂移。

验证：
- cargo test -p db --lib：1301 passed / 0 failed
- rustfmt --edition 2024 --check crates/db/src/manager.rs：clean
- cargo clippy -p db --all-targets：无新增告警
- 变异验证：把 transactional + Error 分支的保守失效改回 false，该测试干净断言失败

- ci.yml: test job 移除 Build ATL/MSVC probe 步骤，新增 windows-rdp-probe 独立 job（x64/i686 双 target 并行），并重新纳入 ci-gate needs，避免 Windows 测试 job 被探针编译拖长

- windows_rdp_host contract: ci.yml 结构断言改用 test / windows-rdp-probe 两段作用域，钉住探针 job 的步骤顺序、-Target 矩阵与 gate 依赖

…ndeterminism

fix(db): 流式缓存测试脱离 GPUI 调度器以消除调度竞态

- 从索引移除 .finch/permissions.json（本地权限状态，属本机产物），文件保留在磁盘

- .gitignore 忽略 .finch/，避免后续 checkpoint 提交再次把它带进仓库

mozilla-actions/sccache-action 从 GitHub Release CDN 下载 sccache 二进制失败
（CI run 35347089674 上连续两次 HTTP 504）会直接让整个 test job 变红，
Windows 测试根本没跑到，ci-gate 随之拦截合并。sccache 只是构建加速器，
不应成为测试或发布 job 的可用性依赖。

- Setup sccache 标记为 continue-on-error: true；该 action 的 post step 复用同一个
  Pipelines.ActionStep，因此继续性错误同样覆盖 post step 失败
- Initialize sccache 在 steps.sccache.outcome != 'success' 时输出 warning，并向
  GITHUB_ENV 写入空 RUSTC_WRAPPER，让后续 cargo 走无缓存构建；空值与 ci.yml
  中 windows-rdp-probe job 的 RUSTC_WRAPPER: "" 是同一语义
- 同步 release.yml 的同一段路径，避免发布 job 被同类瞬时故障打断
- script/test-release-packaging.mjs 的共享缓存策略契约补上 best-effort 断言，
  防止后续改动把这两个步骤改回硬依赖

验证：
- ruby -ryaml 解析两个 workflow：jobs 与步骤结构不变
- node --test script/test-release-packaging.mjs：26 passed / 0 failed
- cargo test -p windows_rdp_host --test contract：39 passed / 0 failed
- 变异验证：临时删掉 ci.yml 的 continue-on-error，共享缓存策略契约立即转红
- 本地 RUSTC_WRAPPER="" cargo check 正常，确认空值等价于不启用 wrapper