fix(tui): swallow 404 when auto-syncing referenced subagent session

[sjawhar]

Issue for this PR

Closes #29350

Type of change

• Bug fix

What does this PR do?

Subagent sessions are ephemeral — they can be GC'd, deleted, or never persisted depending on agent lifecycle. The parent session's Task message still references the subagent ID, and when the TUI auto-syncs that reference and the session is gone, the backend 404 propagates as an unhandled rejection.

One-line .catch(() => {}) on the auto-sync call. Comment explains the lifecycle reasoning. Task message still renders fine without the subagent message preview.

How did you verify your code works?

Manual repro: opened a session with subagent Task references, removed the subagent session, reopened the parent. Pre-fix: error toast / failed render. Post-fix: clean render, no toast.

The auto-sync call is fire-and-forget by design so there's no existing test path covering the rejection — adding a unit test would require mocking the entire SDK client.

Checklist

• I have tested my changes locally
• I have not included unrelated changes in this PR

[ghost]

The following comment was made by an LLM, it may be inaccurate:

Based on the search results, I found one potentially related PR:

Related PR:

• fix(tui): prevent crash when task references missing child session #26944 - fix(tui): prevent crash when task references missing child session
  • URL: fix(tui): prevent crash when task references missing child session #26944
  • This appears to address a similar issue where the TUI needs to handle cases when a task references a session that no longer exists. It's related to the same problem domain of missing/deleted subagent sessions causing crashes.

The current PR (#29353) is more specific about swallowing the 404 error during auto-sync, while #26944 deals with preventing crashes when tasks reference missing child sessions. They may be addressing complementary aspects of the same issue.

[ghost]

Thanks for updating your PR! It now meets our contributing guidelines. 👍

[sjawhar]

Closing in favor of #26944, which lands the same fix plus a navigation guard for the dead-link case. Cherry-picked their content into our fork locally so we get the fix without an extra upstream PR.