Callback Semantics and Application Coordination

STConversationCallback serves two different purposes: observation and synchronous coordination.

Some callbacks are naturally observational—for example, an application may update status UI when a module starts. Others can participate directly in the Conversation's next decision.

The important rule is:

If SpeechTiles must observe an application change for its immediate next decision, complete that change before the callback returns.

This applies to changes such as:

• setting STSRData.clientRejectedHypothesis;
• writing a runtime field used by the current flow; and
• setting user intent that should affect the current transition.

UI work does not need to block Conversation processing. A useful architecture is to perform the small Conversation-critical update synchronously, then publish UI changes separately on MainActor.

This distinction prevents a subtle integration bug in which an application receives the right callback but dispatches all work asynchronously, allowing the Conversation runtime to continue before the application has supplied the state needed for its decision.