手机远控:排队路径(maker:input:enqueue → drain)拿不到来源,客户端说明不生效

承接 #1471 的已知缺口。

## 现状

#1471 让手机来源的**直发**轮次(`maker:send`)带上客户端说明,让 agent 倾向产出自包含单文件。
判据走被控端盖章的 `DeviceLinkInvokeContext.controllerPlatform`(AsyncLocalStorage)。

**排队路径不覆盖**:手机在 agent 忙时走 `maker:input:enqueue`
(`apps/mobile/src/device-link/mobileMakerTransport.ts:740`),消息先入 coordinator 队列,
drain 时才真正派发(`apps/desktop/src/main/maker-ipc/register.ts` 的 drain 会重新走
`sendToAgentAccepted`)。drain 发生在原 invoke 上下文之外,`isMobileControllerInvoke()` 读不到来源。

## 用户会遇到什么

一边跑一边追问是手机上很常见的用法。那些排队轮次拿不到说明,agent 可能仍产出需要同目录资源的
多文件产物。不影响正确性(客户端已能回取同目录资源渲染它,见 #1441 / #1455),但偏好提示在这些
轮次上不生效,表现为「有时是单文件、有时不是」的不一致。

## 为什么没在 #1471 里一起做

需要把来源盖章在入队项上、经 coordinator 队列透传到 drain(现成参照:scheduler 的
`SendOrigin` 就是这么透传的,见 `packages/maker-core/src/types/events.ts` 的 SendOrigin 注释与
`AgentInputSendOpts.origin`)。但 `apps/desktop/src/main/maker-ipc/agent-input-coordinator.ts`
是本仓公认的高风险状态机,与 #1471 混在一起会显著放大评审面。

## 两条不能走的路(先记下来,避免重复讨论)

1. **不能让手机自报来源**。`sendOpts` 是经线上帧传来的客户端可控数据,device-link allowlist
只挡 channel 不挡 args(见 `packages/device-link/src/allowlist.ts` 头注与 dispatch 内说明)。
自报等于不设防,必须由被控端盖章。
2. **不能把注入点上移到 dispatch 层**。落库内容是从同一条传入消息 normalize 出来的
(`makerSendTransaction.ts` 的 `prepareSendUserMessage`),在 dispatch 改写消息会把说明一起
写进用户消息、污染界面上显示的原话 —— 而「只进 wire、不进落库原话」正是该机制的不变量。

## 验收标准

- 手机在 agent 忙时发的消息,drain 派发那一轮同样带上客户端说明。
- 桌面本机 / 桌面远控 / 平台未知的排队轮次**不带**说明(fail-closed 不变)。
- 落库与界面显示的用户消息原话仍不含说明(沿用 #1471 的源码级守卫口径)。
- 来源仍不采信客户端自报字段。

Start at apps/mobile/src/device-link/mobileMakerTransport.ts:740 and trace the queued message into apps/desktop/src/main/maker-ipc/agent-input-coordinator.ts and the drain in register.ts. Read SendOrigin in packages/maker-core/src/types/events.ts and AgentInputSendOpts.origin as the propagation reference. Done means mobile queued rounds carry the stamped origin, while desktop or unknown origins remain fail-closed and stored user text is unchanged.

Written by the indexing model from the issue text.