test(download): 补强最后一跳 + 写明「抓得住/抓不住」（M292 r1）

复审与塔的门禁在本 worktree 报了一条 `left: 120s / right: 300s`
（`changed_settings_reach_the_engine_config_and_the_budget`）。归因结论：**不是源码缺陷**，
是目标目录里跑到了不属于这棵树的 `unlucky_core` 测试二进制。本轮只做两件事：

## 1. 最后一跳补强（presenter）

`the_three_timeout_keys_travel_from_the_file_to_the_engine_config` 此前是自己拼
`tuning.apply_to(EngineConfig::default())`，即「调优 → 引擎」这一跳是**用例自己接的**，
守不住「宿主有没有把调优交给 core」。现在改走 GUI 的生产装配点
`crate::host::engine::engine(&env)`（内部 `apply_tuning` → `shared::set_tuning` → 按数据根重建），
断言读 `engine.config()`。这一步断了（宿主没调 `apply_tuning`、或 `shared` 装配点没用
`apply_to`），三条断言全红。

## 2. 用例文档写清边界（config/tests.rs）

`changed_settings_reach_the_engine_config_and_the_budget` 的文档补上返工取证：

- **抓得住**（三键逐一变异，删掉 `apply_to` 里对应赋值即红）：
  `response_timeout` ⇒ 278 行 `60s/180s`；`chunk_stall_timeout` ⇒ 279 行 `120s/300s`；
  `min_avg_throughput` ⇒ 280 行 `32768/16384`。另抓 `from_raw` 的 KiB→字节换算与
  `chunk_job_budget` 忽略下限。
- **抓不住**：①宿主有没有调用 `tuning`/`apply_to`（前半段归宿主用例）；②跑的是不是这棵树的
  二进制（编译期常量与代码内容都不在它视野里 —— 本轮就栽在这里）。

`config/tests.rs` 因此从 394 → 398 行（仍在 400 硬线内）。

crates/presenter/src/host/settings/download_tests.rs

@@ -319,13 +319,15 @@ fn the_gh_proxy_key_travels_from_the_file_to_the_core_tri_state() {
 /// 它们唯一的入口，也正是因此这里要逐字段断言，而不是只看「行上画了什么」。
 ///
 /// 抓得住：① 宿主少读一个键（例如漏了 `KEY_THROUGHPUT_FLOOR`）⇒ 对应断言红；② KiB→字节换算写错
-/// （少乘 1024）⇒ 吞吐下限那条红；③ 回落口径被改成「夹到边界」⇒ 越界那条红。
+/// （少乘 1024）⇒ 吞吐下限那条红；③ 回落口径被改成「夹到边界」⇒ 越界那条红；④（M292 返工后补强）
+/// `host::engine::engine` 这一跳 —— 它内部的 `apply_tuning` 没被调用、或 `shared` 装配点没用
+/// `apply_to`，`engine.config()` 就是出厂值，三条断言全红。
 /// 抓不住：真机慢链路的实际体验（离线环境，见 M292 报告的未验项）。
 #[test]
 fn the_three_timeout_keys_travel_from_the_file_to_the_engine_config() {
     use std::time::Duration;
     use unlucky_core::download::config::{
-        EngineConfig, KEY_CHUNK_STALL, KEY_RESPONSE_TIMEOUT, KEY_THROUGHPUT_FLOOR,
+        KEY_CHUNK_STALL, KEY_RESPONSE_TIMEOUT, KEY_THROUGHPUT_FLOOR,
     };
 
     let (dir, env) = env_with(
@@ -341,8 +343,12 @@ fn the_three_timeout_keys_travel_from_the_file_to_the_engine_config() {
     assert_eq!(tuning.chunk_stall_timeout, Duration::from_secs(300));
     assert_eq!(tuning.response_timeout, Duration::from_secs(180));
 
-    // 引擎拿到的是同一组值（`apply_to` 是装配点唯一的一跳）。
-    let cfg = tuning.apply_to(EngineConfig::default());
+    // 引擎拿到的是同一组值 —— **走 GUI 的生产装配点**：`host::engine::engine`（内部先
+    // `apply_tuning` → `shared::set_tuning` → 按数据根重建），不是本用例自己拼一个 `apply_to`。
+    // 这一跳要是断了（宿主没把调优交给 core），下面的断言就红。
+    std::fs::create_dir_all(env.layout.cache()).expect("cache 目录");
+    let engine = crate::host::engine::engine(&env);
+    let cfg = engine.config();
     assert_eq!(cfg.min_avg_throughput, 16 * 1024);
     assert_eq!(cfg.chunk_stall_timeout, Duration::from_secs(300));
     assert_eq!(cfg.response_timeout, Duration::from_secs(180));