补齐广播、扫描与建链的真实 DLI 事务

[sanchuanhehe]

What to build

让广播、扫描和建链从管理 Interface 一直走到真实 Controller Backend，并由 DLI Host Module 完成完整标准命令事务。

当前广播路径构造了参数和 PDU，但没有依次发送参数、广播数据、扫描响应数据后再 Enable；扫描只 Enable，没有先下发 Scan Parameters；建链只发送对端 6 字节地址，缺少地址类型、扫描窗口、PHY、带宽、连接间隔、latency、supervision timeout 等标准字段。这些路径在虚拟状态机里看似成功，但不足以驱动真实控制器。

已公开的 OpenHarmony Implementation 进一步证明，真实闭环至少包含四个可独立验证的阶段：DLI Host 事务编码、通用 H4/DLI Channel framing、Backend/channel 交付、芯片返回 event。公开通用代码并不等于真正芯片 vendor Adapter 已存在。

Acceptance criteria

• Backend start、channel ready 与标准 DLI 事务分离；Backend 未 ready 时 Host 不提交命令。
• 广播按标准和 controller capability 执行 Set Parameters、Set Data、Set Scan Response、Enable 的有序事务。
• 扫描先配置完整参数，再 Enable；active/passive、filter 和窗口约束有明确校验。
• 建链编码完整 typed 参数，而不是只发送地址。
• 每一步关联 CommandStatus 或 CommandComplete，并等待需要的领域完成事件；失败、timeout 和取消会回滚 Host 状态。
• DLI version/capability 来自标准查询或明确 controller handshake，不能从 HDI Interface v1.0/v1.1、产品配置或 Backend 类型猜测。
• 同一 typed transaction 在 NativeBackend、OpaqueVendorBackend 与 VirtualBackend 上产生一致的标准 DLI packet。
• DLI Host golden packet 测试覆盖命令顺序、参数和 event correlation。
• 内部 DliChannel 测试覆盖 packet type、H4/DLI header、partial read/write、EAGAIN、多个 packet 连续到达和畸形长度。
• fake 或 VirtualBackend 可以驱动完整 event 回路，但测试结果不得被描述为硬件成功。
• vendor Adapter 缺失、Backend probe 失败、channel open 失败或 init timeout 时，事务不得进入 Host 成功状态。
• 至少一个真实硬件支持的 Channel Adapter trace 证明 packet 到达芯片并收到 controller event；可以是 USB、serdev 或 opaque vendor fd channel。
• 禁止 Adapter、本地 worker 或测试替身伪造 CommandComplete 作为硬件验收。

Reference evidence

• OpenHarmony 通用 framing/watcher/vendor loader：drivers_peripheral PR 8987，提交 b97be697c9cf0484305446f9a3f5104b74c8a629。
• 真实 libnearlink_sle_vendor[_chiptype].z.so 未随公开源码提供，因此不能把通用 HDI 编译成功当成芯片闭环完成。

Blocked by

• 明确 DLI Host、Controller Backend 与内部 Channel Seam #1