[Fix] Slack Fast threads remain titled Thread after completed answers

[roomote-roomote]

​Opened on behalf of @daniel-lxs. Follow up by mentioning @roomote-roomote, in the web UI, or in Slack.

What changed

• Fast title refreshes now report only title values actually changed by that persistence attempt.
• Persisted generated titles queue a best-effort Slack agent-session rename directly, even when turn activity already settled or Slack status responses omit the current title.
• If that direct rename races before Slack session creation and fails, the same turn retries once after a successful status update has had a chance to create the session.
• Blank and unchanged titles remain no-ops, duplicate attempts are suppressed within a turn, and rename failures remain non-fatal.

Why this change was made

The existing rename path waited for delayed turn activity and required agents.sessions.setStatus to report a mismatched title. A short first turn could settle before that activity started, so its asynchronously generated title persisted in Roomote without ever notifying Slack. Later turns below the next title checkpoint made no new persisted title change, and status responses that omitted the current title gave them no mismatch to repair.

Impact

New Slack Fast threads can receive their generated title without requiring another message. The existing processing/active status lifecycle remains unchanged, while generated-title notifications no longer depend on its timing or response shape. Previously stuck threads are not renamed retroactively by unchanged later turns.

[roomote-community]

1 issue outstanding. See task

• packages/slack/src/fast-agent-session-activity.ts:127 Short turns can still attempt a rename before Slack has a session to rename.

_{Reviewed b79bd4e}

[roomote-community]

When a turn settles before the 300 ms timer, settle() cancels the only setAgentSessionStatus call, so there is no Slack agent session to rename. A generated title arriving afterward reaches this direct rename, receives false for the missing session, and has no later status update to trigger the retry. This is the short-turn path the PR is meant to fix; create the session (or retain a retryable pending title) before treating that rename failure as terminal.