Does Reach specify a retry policy when a participant's RPC call to the consensus network times out?

I'm building a Reach DApp with two participants (a deployer and an attacher) targeting Algorand, compiled with a recent Reach release. The generated frontend stubs in build/index.main.mjs handle all communication with the consensus network through the connector, and I have no user-facing configuration for transport behavior.

My uncertainty: when a participant's publish or a ctc.getInfo()-style RPC call stalls or times out, I cannot find anything in the language reference that defines what happens next. The language spec covers publish, commit, and transfer semantics, but the retry, backoff, and timeout behavior appears to live entirely in the connector implementation (ALGO vs ETH), and I don't know whether those connectors even agree on a policy.

This matters because my frontend needs to decide whether to surface a failure to the user or wait, and I can't tell whether a hung call will eventually resolve, throw, or silently leave the participant out of sync with consensus state.

1. Does Reach define any default timeout or retry/backoff behavior for participant RPC calls, or is it entirely connector-specific?
2. If a connector RPC call fails mid-interaction, does the participant's local view of the application state remain consistent, or must the application handle recovery?
3. Is there a documented way to observe or hook into these transport failures from the JavaScript standard library?