fix: restored sidebar state after session reload

[ljie-PI]

Summary

• persist sidebar session state in chat history so restored sessions keep their last terminal state
• stop inferring generating from replayed assistant text messages during history/session restore
• only allow replayed intermediate states like thinking and active tool calling to override state while a request is actually active

Why

Restoring a previous session could show the wrong sidebar state because current_state was not persisted and was re-inferred from replayed history messages. This was especially visible with ACP providers like opencode, where restored history could incorrectly replace a finished state such as succeeded with generating or thinking.

Changes

• add last_state to persisted chat history
• restore current_state from persisted history on reload
• save state transitions through on_state_change()
• remove the fallback that treated non-tool, non-thinking messages as generating
• gate replay-driven intermediate state updates on whether the current state is part of an active request

[github-actions]

This PR is stale because it has been open 14 days with no activity. Remove stale label or comment or this will be closed in 10 days.

[ljie-PI]

Any feedback on this? @yetone

[github-actions]

This PR is stale because it has been open 14 days with no activity. Remove stale label or comment or this will be closed in 10 days.

[ljie-PI]

don't we need this?

[github-actions]

This PR is stale because it has been open 14 days with no activity. Remove stale label or comment or this will be closed in 10 days.

[teto]

I noticed there were issues in master. I will have a look after a few other merges.

[github-actions]

This PR is stale because it has been open 14 days with no activity. Remove stale label or comment or this will be closed in 10 days.

[teto]

maybe self.request_pending() ?

[teto]

persist sidebar session state in chat history so restored sessions keep their last terminal state
stop inferring generating from replayed assistant text messages during history/session restore

I am not familiar with the code and all the states but it seems odd that we would have to store the state.
Inferring state makes sense at first glance, with the caveat that if when loading it from history, one could override it so it doesn't show as pending.
When reloading (or before saving state), I would assume that we can't set something to an active/pending state. That is we shouldn't have a "generating"/"searching"/"thinking" after loading from history but just a final state like "failed"/"cancelled"/"succeeded" ?

Eventually we can look at what other harnesses do and copy their behavior

[github-actions]

This PR is stale because it has been open 14 days with no activity. Remove stale label or comment or this will be closed in 10 days.

[teto]

do you have a way to reproduce the issue to check this fixes the issue ?