await-ui-element announces "UI element appeared" for a wait that timed out: completedMsg ignores success:false

Start in packages/tool-server/src/tools/await-ui-element/index.ts around lines 159-164 and 350, then compare the result-aware completedMsg in packages/tool-server/src/tools/keyboard/index.ts. Trigger a selector that never matches and let it time out; the interaction message should no longer claim success when result.success is false, while successful waits should retain their existing messages.

[Diplomat, Opus 5]: Found while reviewing #592, which fixes the same class in keyboard. Out of scope there, so filing it here.

await-ui-element reports an unmet wait in its RESULT (success: false) rather than by throwing, so the interaction line the user sees comes from completedMsg — which never looks at the result:

packages/tool-server/src/tools/await-ui-element/index.ts:350

      completedMsg: ({ params }) => conditionCompleted[params.condition],

with (:159-164)

const conditionCompleted = {
  exists: "UI element appeared",
  visible: "UI element became visible",
  hidden: "UI element became hidden",
  text: "UI element matched expected text",
} as const;

So a condition: exists wait that ran its full timeout and came back { success: false, elapsed: 10000, note: … } is announced as "UI element appeared". The line states the opposite of what happened, on the one tool whose whole purpose is to report whether the state arrived.

Trigger: call await-ui-element with a selector that never matches (any condition) and let it time out. The result is correct; the message beside it is not.

The twin that does it right is keyboard, whose verdict has the same shape (reported, not thrown) — packages/tool-server/src/tools/keyboard/index.ts:

      completedMsg: ({ params, result }) =>
        params.text === undefined
          ? "Pressed a key"
          : `Entered text${result.verified === false ? " (text did not land)" : ""}`,

completedMsg already receives result, so the fix is local: qualify the string when success is false (and the note says why).

Why it matters beyond cosmetics: the same "reported, not thrown" shape is what the recorder's UNMET_WAIT_WARNING and flow-run's gate exist to catch, because a green-looking wait becomes a flow step that fails at replay. The interaction line is the one place that still reads as success.