docs: make H264 gate content independent

docs/adr/0007-path-isolated-representation-quality.md

@@ -22,9 +22,12 @@ it does not need a second bitrate, resolution, FPS, or layer-control system.
 
 ## Decision
 
-1. Browser video makes one internal, source-scoped codec decision. A bounded
+1. Browser video makes one internal, sender-scoped codec decision. A bounded
    actual-`RTCPeerConnection` preflight measures H.264 encoded progress against
-   the same source progress. A proved source prefers H.264 and retains VP8 as
+   a deterministic moving probe track at the current share's effective target
+   dimensions and frame rate. The real capture supplies those target settings,
+   but its current motion does not decide encoder capability. A proved sender
+   prefers H.264 and retains VP8 as
    the native negotiation fallback; an unsupported, inconclusive, slow, or
    failed preflight uses VP8 only. The result is not persisted or inferred from
    UA, GPU, capability advertisement, or `powerEfficientEncoder` alone.

docs/project-memory.md

@@ -70,8 +70,10 @@ Last updated: 2026-08-26
 ## Media Quality
 
 - Current source and production still use VP8 only. The accepted next Browser
-  contract runs one source-scoped actual-sender preflight: proved sources prefer
-  H.264 with native VP8 fallback, while failed/inconclusive sources remain
+  contract runs one sender-scoped actual-sender preflight with a deterministic
+  moving probe track sized to the current share target, so captured-content
+  motion cannot decide encoder capability. Proved senders prefer
+  H.264 with native VP8 fallback, while failed/inconclusive senders remain
   VP8-only. Codec UI/state/wire, persistent codec cache, parallel codec media,
   backup publication, and active-edge codec switching remain absent. Display
   video uses `contentHint = "motion"` and display audio uses `contentHint = "music"`.

docs/status.md

@@ -56,8 +56,8 @@ This is the current execution index. Git history owns completed timelines;
 
 ## Current Milestone
 
-1. Implement the accepted source-scoped Browser H.264 preflight and VP8 fallback
-   across direct, Browser relay, and the Host's single SFU publication. Current
+1. Implement the accepted content-independent Browser H.264 sender preflight
+   and VP8 fallback across direct, Browser relay, and the Host's single SFU publication. Current
    source and production remain fixed VP8 until that candidate is integrated and
    separately released.
 2. Remove the client-side preferred-room expiry/renewal timer while keeping the

docs/todo.md

@@ -7,9 +7,10 @@ later topic is not implementation authority by itself.
 
 ## Now
 
-1. **Adaptive Browser H.264.** Implement the accepted source-scoped actual-sender
-   preflight. Proved Host/relay sources prefer H.264 with native VP8 fallback;
-   failed or inconclusive sources use VP8. The Host decision owns its one SFU
+1. **Adaptive Browser H.264.** Implement the accepted sender-scoped actual-sender
+   preflight with a deterministic moving probe track at the current share target.
+   Proved Host/relay senders prefer H.264 with native VP8 fallback;
+   failed or inconclusive senders use VP8. The Host decision owns its one SFU
    publication with backup codec disabled. Add no codec UI, wire state,
    persistent cache, parallel codec route, or active-edge churn.
 2. **Preferred room simplification and replacement.** Keep the server dormant

docs/方案设计.md

@@ -162,7 +162,7 @@ accepted 的唯一 wire 是 `screener-v12`，不做版本协商、旧 parser、
 
 每次 `setParameters()` 都必须从当次 `getParameters()` 派生更新，然后读回 requested/applied `maxBitrate`、`maxFramerate`、`scaleResolutionDownBy` 和 degradation preference。浏览器负责具体降级，实际结果由 stats 观测；拒绝或浏览器改写必须进入可见状态，不能只写 `console.warn`。
 
-Accepted `screener-v12` Web 视频使用页面内 source-scoped H.264/VP8 决策。初始 Host capture 在取得 room/route authority 前，以一对无 ICE server 的本地标准 `RTCPeerConnection` 运行一个有界 H.264-only sender probe；只用实际协商 codec、同一身份的 media-source/encoded progress 与 bounded completion 判断，不读取 UA/GPU/MFT allowlist，也不单独相信 capability 或 `powerEfficientEncoder`。成功结果让后续 P2P/browser-relay offer 按浏览器原生 H.264 capability 顺序列出 H.264，再列 VP8 与 RTX/RED/FEC repair capabilities；失败或 inconclusive 只列 VP8 与 repair。Relay 收到新 upstream stream 后在后台运行同一 gate，完成前建立的 child 使用 VP8，完成后只影响未来 child。无法应用 codec preferences 或缺少 VP8 时明确失败。SFU publication 使用 Host source 当时的同一 H.264/VP8 决定并关闭 backup codec。所有新 Web peer sender 与 SFU publication 保留 `motion` 和用户选择的分辨率、帧率及码率 ceiling；当 desired degradation preference 允许分辨率下降时，启动阶段的 effective preference 暂为 `maintain-resolution`，当前 sender 累计编码至少五帧后由既有 stats 路径一次性应用 desired preference。该切换使用标准 `setParameters()` 进入或离开 balanced 时的原生 restriction reset，不增加周期重写、质量评分或应用层调档器。UI 和 quality state/wire 没有 codec 字段；gate 结果不持久化、不改写已连接 edge，实际 outbound codec/profile、encoder implementation 与 stats 是只读结果真相。应用 SDP 变换边界仍只有 Viewer answer 的 Opus stereo receive preference。
+Accepted `screener-v12` Web 视频使用页面内 sender-scoped H.264/VP8 决策。初始 Host capture 在取得 room/route authority 前，以一对无 ICE server 的本地标准 `RTCPeerConnection` 运行一个有界 H.264-only sender probe。Probe 使用按当前分享 effective target dimensions/frame rate 生成的短时确定性运动 Canvas track，并以 `motion` 表达同一内容意图；真实 capture/upstream track 只提供目标规格，其当前内容是否变化不参与 encoder capability 判断。Gate 只用实际协商 codec、同一身份的 probe media-source/encoded progress 与 bounded completion 判断，不读取 UA/GPU/MFT allowlist，也不单独相信 capability 或 `powerEfficientEncoder`；标准 Canvas capture 不可用、失败或 inconclusive 时使用 VP8。成功结果让后续 P2P/browser-relay offer 按浏览器原生 H.264 capability 顺序列出 H.264，再列 VP8 与 RTX/RED/FEC repair capabilities；失败或 inconclusive 只列 VP8 与 repair。Relay 收到新 upstream stream 后在后台运行同一 gate，完成前建立的 child 使用 VP8，完成后只影响未来 child。无法应用 codec preferences 或缺少 VP8 时明确失败。SFU publication 使用 Host source 当时的同一 H.264/VP8 决定并关闭 backup codec。所有新 Web peer sender 与 SFU publication 保留 `motion` 和用户选择的分辨率、帧率及码率 ceiling；当 desired degradation preference 允许分辨率下降时，启动阶段的 effective preference 暂为 `maintain-resolution`，当前 sender 累计编码至少五帧后由既有 stats 路径一次性应用 desired preference。该切换使用标准 `setParameters()` 进入或离开 balanced 时的原生 restriction reset，不增加周期重写、质量评分或应用层调档器。UI 和 quality state/wire 没有 codec 字段；gate 结果不持久化、不改写已连接 edge，实际 outbound codec/profile、encoder implementation 与 stats 是只读结果真相。应用 SDP 变换边界仍只有 Viewer answer 的 Opus stereo receive preference。
 
 Web display-audio 请求显式关闭 `echoCancellation`、`noiseSuppression`、`autoGainControl` 和 `voiceIsolation`，并以 `channelCount: { ideal: 2 }` 偏好双声道；这是当前 Chrome/Edge Host 基线的实现契约，用于避开网页 `getDisplayMedia()` 默认的语音处理和单声道 APM 候选，不宣称跨浏览器保证，也不固定采样率。所有值都是非强制 post-selection preference；不使用 `exact`、`min` 或 `advanced`。若 `getAudioTracks()` 为空，分享者界面必须显示“当前来源没有可共享音频”。Web 端同时传入 `windowAudio: "window"` 与 `systemAudio: "include"`：窗口选项请求该窗口/应用音频，整个屏幕选项允许用户勾选系统音频；标签页使用浏览器自身的标签页音频选择。浏览器可以忽略这些约束或 picker hints，且没有对应的标准来源类型读回，因此 UI 不额外推断或标注来源。系统音频由用户显式选择，可能包含语音或通知；video-only 始终可用。