Document or normalize soft wraps in ui.waitFor text matching

Drive 2.1.0, Bun 1.4.0, OpenCode V2 97303c39dd153b64d7036249b279490201820b19, a 100x32 TUI.

A visible reply can fail ui.waitFor("No sourcebook tools are available yet.") when the substring crosses a terminal soft wrap. The model reply was:

The sourcebook executable is ready, but it is not connected. No sourcebook tools are available yet.

The scripted response completed, but the wait timed out after 5000ms with UiWaitTimeoutError. Adding a paragraph break before “No sourcebook tools…” made the unchanged wait pass. The server-side request/history path was not failing.

It would help to document whether string matching is against physical terminal lines, or offer an opt-in soft-wrap-normalized match. The error object's frame.lines printed as [Object ...] through run, so identifying the wrap required inspecting the recording.

Expected: either a documented physical-line matching contract, or a way to wait for visible prose independently of soft wrapping. No runtime change is needed for the workaround: use a shorter visible substring or a semantic/server-side predicate.

Start with the ui.waitFor entry point and reproduce the 100x32 TUI case using the visible reply and the existing wait call. Inspect the recorded frame and frame.lines output to determine the current physical-line behavior. Done means either documenting that matching contract or providing and verifying an opt-in soft-wrap-normalized match, with the chosen scope made explicit.