feat(tui): keep /tasks Preview Output fresh and surface load errors

What feature would you like to see?

Make the /tasks Preview Output panel refreshable and trustworthy for the currently selected task.

Today the panel fetches getBackgroundTaskOutput(taskId, { tail: 4000 }) once when a task is selected. If the task is still running at that moment, the preview remains empty even when output arrives later or a subagent successfully completes. R refreshes task metadata but does not retry the selected task's output request. In addition, a rejected output request is rendered as the same [no output captured] state as a genuinely silent task.

This makes a long-running task difficult to distinguish from a stuck task, and can leave a completed task looking empty until the user changes selection or reopens /tasks.

Suggested behavior:

• Refresh the selected task's preview when its task metadata or output changes, while avoiding unnecessary repaint/request churn.
• At minimum, make R retry the selected preview and refresh it once the selected task reaches a terminal state.
• Show a distinct, actionable error state when preview retrieval fails (for example, Cannot load preview: … plus a retry hint) rather than reporting [no output captured].
• Preserve the existing tail limit, selection/request-id race protection, and full-output viewer behavior.

Additional information

This is complementary to #667 and its open implementation PR #2130, which add live subagent events to the background task output buffer. Even after that output exists, the /tasks preview needs to re-fetch or subscribe to it; otherwise an initial empty fetch can remain stale for the lifetime of the browser dialog.

Relevant current paths:

• apps/kimi-code/src/tui/controllers/tasks-browser.ts: loadTail() fetches once on selection; its rejection path assigns an empty preview.
• apps/kimi-code/src/tui/components/dialogs/tasks-browser.ts: an empty tail is rendered as [no output captured].

Suggested acceptance criteria:

1. Select a running background agent whose output is initially empty, wait for it to succeed, and observe its final result without changing selection or reopening /tasks.
2. A running process task's recent stdout/stderr becomes visible in the selected preview after output arrives.
3. A failed preview fetch is visibly distinguishable from a task that emitted no output and can be retried.
4. Existing stale-response protection continues to prevent an older selected task's result from overwriting the active selection.

Start in apps/kimi-code/src/tui/controllers/tasks-browser.ts, tracing loadTail(), refresh handling, rejection state, and selection/request-id protection; then inspect apps/kimi-code/src/tui/components/dialogs/tasks-browser.ts for preview rendering. Exercise the acceptance criteria with running, completed, silent, and failed tasks, ensuring output refreshes without reopening the dialog and errors remain distinct and retryable.