Compose the opening announcement. Pure, so the wording is unit-testable without a device. Periods between the blocks make the reader pause between them, matching the cadence of the built-in dialog.

focusedText is what the dialog's focused element is (a button label), included so the whole announcement is ONE utterance — see narrateDialogOpening for why it can't be left to the platform.

Announce a dialog that has just opened, as a single utterance.

TIMING — measured on-device, and counter-intuitive. The platform announces the focused element as soon as focus lands, and that announcement does NOT queue behind ours: it FLUSHES it. Speaking before handing over focus produced about three words of the title and then "Cancel", which is worse than saying nothing.

So the caller waits for focus to settle and speaks LAST, with the focused button's label folded into our own text. Ours is then the utterance that wins, and it comes out in the built-in order: title, message, focused button.

Announce the element focus just moved to.

Needed because the platform does NOT narrate focus moves between the buttons in a dialog's row — measured on-device: after the opening announcement, arrowing between Cancel and Confirm was completely silent. TextButton extends Group, not Roku's Button, so the documented "text of button is spoken only if focused" rule never applies to it.

Flushes rather than queues, so arrowing quickly through options announces the one you landed on instead of reading a backlog of the ones you passed.