0.7.x regression: long-running chat/integration turns outlive frontend waiting; need first-class resumable run/progress model

[voarsh2]

• 0.7.x seems much more fragile for long-running turns than 0.5.x.
• In practice, the backend often keeps working and eventually finishes, but the frontend/client stops showing meaningful progress and may appear dead until refresh.

This is especially noticeable for:

• first replies
• integration-heavy asks
• self-hosted setups with slower hardware or flaky upstream APIs

The problem is less “the request is slow” and more:

• the frontend/backend contract for multi-minute work is too fragile

Right now, long-running turns seem too dependent on a live frontend transport surviving the whole orchestration chain.

• If backend work is still running or even completed the client should be able to:
  • keep showing durable progress
  • reattach cleanly after refresh/timeout
  • discover the final result without manual recovery guesswork
• I’m not asking for a full rewrite.

I’m asking for more first-class handling of long-running chat/integration turns:

• durable server-side run state
• durable progress events
• reliable resume/reattach behavior
• frontend waiting based on server truth, not just live transport state