修正 BGM 提示词助手限流用例的断言口径：只承诺客户端可见语义

- server-rs/crates/api-server/src/editor_background_music_prompt_assist.rs：consecutive_valid_requests_are_not_subject_to_a_feature_rate_limit
  的 assert_eq!(mock.finish().len(), 4) 改为「到达 provider 的请求不少于 4 次」，并在该断言失败时打印捕获到的请求原文

为什么新形态才是它真正承诺的语义：用例名只承诺「连续合法请求不被特性限流」，那是客户端可见口径；
本模块的简化路径本身允许一轮内容重试（同文件 simplification_retries_* 四条用例正是它的定向覆盖），
因此 provider 的精确调用次数是实现细节，把它钉死会让一次合法重试变成假红。
「4 次调用都到达 provider」与原有的 200/非 429 断言都保留：短路、提前拒绝、限流仍然会红。
根因见 #327 问题 2.2（PR #316 run 1950：left: 5, right: 4）。

.gitea/workflows/project-ci.yml

@@ -232,6 +232,37 @@ jobs:
             done
           done
 
+      - name: Prepare standalone Rust crate dependencies
+        shell: bash
+        run: |
+          set -euo pipefail
+          # agent-runtime-core / agent-runtime-orchestration 被 server-rs/Cargo.toml 的
+          # exclude 排除，不参与上面的 workspace 锁文件，因此上面那次锁定 fetch 覆盖不到它们；
+          # 而 check:native-shells 会经 agent-runtime-*:check 用 `cargo test --manifest-path`
+          # 单独跑这两个 crate。不在这里预热的话，这两条测试会在测试阶段自己
+          # `Updating crates.io index`，crates.io 一抖动整条 native shell 作业就红
+          # （见 #327 / PR #316 run 1950）。
+          # 两个 crate 都没有提交 Cargo.lock，所以这里只能做不带锁标志的 fetch：
+          # 加锁标志会因为缺少锁文件直接失败。生成的 Cargo.lock 落在两个 crate 目录内，
+          # 已被各自的 .gitignore 忽略，只留在容器里；随后的测试阶段因此能用锁定版本
+          # 解析，不再触碰 registry index。
+          for manifest_path in \
+            server-rs/crates/agent-runtime-core/Cargo.toml \
+            server-rs/crates/agent-runtime-orchestration/Cargo.toml; do
+            for attempt in $(seq 1 5); do
+              if cargo fetch \
+                --target x86_64-unknown-linux-gnu \
+                --manifest-path "${manifest_path}"; then
+                break
+              fi
+              if [[ "${attempt}" -eq 5 ]]; then
+                echo "standalone crate dependency fetch failed after 5 attempts: ${manifest_path}" >&2
+                exit 1
+              fi
+              sleep $((attempt * 2))
+            done
+          done
+
       - name: Run native shell gates
         run: npm run check:native-shells
 

scripts/project-ci-workflow.test.ts

@@ -321,4 +321,26 @@ describe('project CI workflow', () => {
     expect(nativeJob).toContain('server-rs/Cargo.toml');
     expect(nativeJob).toContain('cargo fetch --locked');
   });
+
+  it('prefetches the excluded standalone Rust crates before the native shell gates', () => {
+    const standaloneStep = stepSection(
+      'native-shell-tests',
+      'Prepare standalone Rust crate dependencies',
+    );
+    for (const manifest of [
+      'server-rs/crates/agent-runtime-core/Cargo.toml',
+      'server-rs/crates/agent-runtime-orchestration/Cargo.toml',
+    ]) {
+      expect(standaloneStep).toContain(manifest);
+    }
+    // 这两个 crate 没有提交 Cargo.lock，只能用不带 --locked 的 fetch：
+    // 带 --locked 会因为缺少锁文件直接失败。
+    expect(standaloneStep).toContain('cargo fetch \\');
+    expect(standaloneStep).not.toContain('cargo fetch --locked');
+
+    const nativeJob = jobSection('native-shell-tests');
+    expect(
+      nativeJob.indexOf('Prepare standalone Rust crate dependencies'),
+    ).toBeLessThan(nativeJob.indexOf('run: npm run check:native-shells'));
+  });
 });

server-rs/crates/api-server/src/bgfilter_worker.rs

@@ -3558,13 +3558,41 @@ mod tests {
         }
     }
 
-    async fn reserved_loopback_port() -> u16 {
-        let listener = tokio::net::TcpListener::bind("127.0.0.1:0")
-            .await
-            .expect("bind ephemeral port");
-        let port = listener.local_addr().expect("local addr").port();
-        drop(listener);
-        port
+    /// 测试端口带的上下界：**避开内核动态端口范围**。
+    ///
+    /// Linux 默认 `net.ipv4.ip_local_port_range` 是 32768-60999，Windows/macOS 默认动态
+    /// 端口范围是 49152-65535；20000-29999 落在两者之外，内核不会把该带内的端口当作临时
+    /// 端口派发出去。
+    const TEST_PORT_BAND_START: u16 = 20_000;
+    const TEST_PORT_BAND_END: u16 = 29_999;
+
+    /// 进程内分配游标：保证同一测试进程的两个用例不会拿到同一个端口。
+    static TEST_PORT_CURSOR: AtomicUsize = AtomicUsize::new(0);
+
+    /// 测试专用：分配一个「先保持关闭、稍后才监听」的 loopback 端口。
+    ///
+    /// 不能再用 `bind("127.0.0.1:0")` 取临时端口再 drop：本组用例需要在监听尚未开始的
+    /// 那段空窗里独占该端口（父侧必须先在 connect 失败上重试），而空窗期内同一测试
+    /// 二进制里其它用例的 `bind(0)` 完全可能被内核派到同一个端口，于是重新 bind 时报
+    /// `AddrInUse`（#327；本文件两条「重启窗口」用例都踩，run 1950 报的就是它）。
+    ///
+    /// 改为从动态端口范围之外的固定测试带里递增分配，并先探测可用性：内核不会自动派发
+    /// 该带内的端口，只要本进程不重号，空窗期内就没人能抢走它。
+    fn reserved_loopback_port() -> u16 {
+        const BAND_LEN: usize = (TEST_PORT_BAND_END - TEST_PORT_BAND_START + 1) as usize;
+        let start = TEST_PORT_CURSOR.fetch_add(1, AtomicOrdering::Relaxed) % BAND_LEN;
+        for step in 0..BAND_LEN {
+            let offset = (start + step) % BAND_LEN;
+            let port = TEST_PORT_BAND_START + u16::try_from(offset).expect("offset fits u16");
+            // 探测：宿主机上真有进程占用该端口时顺延到下一个。探测用的 listener 立即释放，
+            // 但这不是新的 TOCTOU——该端口不参与内核动态派发，本进程也不会再分配同一个端口。
+            if std::net::TcpListener::bind(("127.0.0.1", port)).is_ok() {
+                return port;
+            }
+        }
+        panic!(
+            "测试端口带 {TEST_PORT_BAND_START}-{TEST_PORT_BAND_END} 全部不可用，无法分配 loopback 测试端口"
+        );
     }
 
     fn find_subslice(haystack: &[u8], needle: &[u8]) -> Option<usize> {
@@ -3575,7 +3603,7 @@ mod tests {
 
     #[tokio::test]
     async fn connect_retry_exhausts_flat_quota_then_returns_connect_error() {
-        let port = reserved_loopback_port().await;
+        let port = reserved_loopback_port();
         let state = parent_client_state(port);
         // 标记已连通：本测试验证的是常规档（运行中途故障）的 flat 快速收口配额。
         state.mark_bgfilter_worker_reached();
@@ -3611,7 +3639,7 @@ mod tests {
     async fn connect_retry_crosses_worker_restart_window_and_stops_on_http_response() {
         use tokio::io::{AsyncReadExt as _, AsyncWriteExt as _};
 
-        let port = reserved_loopback_port().await;
+        let port = reserved_loopback_port();
         let state = parent_client_state(port);
         let audit = parent_audit(None);
         let server = tokio::spawn(async move {
@@ -3685,7 +3713,7 @@ mod tests {
 
     #[tokio::test]
     async fn connect_retry_stops_without_sleeping_when_deadline_cannot_fit_next_round() {
-        let port = reserved_loopback_port().await;
+        let port = reserved_loopback_port();
         let state = parent_client_state(port);
         let call_budget = Duration::from_millis(state.config.bgfilter_call_budget_ms());
         // 父剩余刚好放得下第一次调用（约 300ms 排队额度），放不下「退避 + 再一次完整调用」。
@@ -3763,7 +3791,7 @@ mod tests {
     async fn cold_start_flat_retries_past_regular_quota_until_worker_listens() {
         use tokio::io::{AsyncReadExt as _, AsyncWriteExt as _};
 
-        let port = reserved_loopback_port().await;
+        let port = reserved_loopback_port();
         // 不标记已连通：模拟主机开机后 flat 首次调用，worker 约 2.8s 后才监听——
         // 超出常规档 1.5s 配额，冷启动档必须继续退避跨过窗口。
         let state = parent_client_state(port);

server-rs/crates/api-server/src/editor_background_music_prompt_assist.rs

@@ -846,7 +846,17 @@ mod tests {
         }
 
         let requests = mock.finish();
-        assert_eq!(requests.len(), 4);
+        // 用例名承诺的是「连续合法请求不被特性限流」，所以这里只断言客户端口径：
+        // 4 次调用都必须真正到达 provider（不少于 4 次），且都成功、没有 429。
+        // 不再断言「provider 恰好被调用 4 次」——本模块的简化路径本身允许一轮内容重试
+        // （见 simplification_retries_* 用例），把精确次数钉死会让一次合法重试就变成假红
+        // （#327 / PR #316 run 1950：left: 5, right: 4）。精确次数属于实现细节，
+        // 已由那几条定向重试用例覆盖。
+        assert!(
+            requests.len() >= 4,
+            "4 次客户端调用都必须到达 provider，实际 {} 次：{requests:#?}",
+            requests.len()
+        );
         for (status, payload) in responses {
             assert_eq!(status, StatusCode::OK, "{payload}");
             assert_ne!(status, StatusCode::TOO_MANY_REQUESTS);