feat(agent): continue scheduled task results in chat

[Nikhil (shadowfax92)]

Fixes #949

Verification:

• Passed: bun test apps/agent/lib/schedules/scheduledChatContext.test.ts apps/agent/entrypoints/sidepanel/index/useChatSession.test.ts apps/agent/entrypoints/newtab/layout/route-utils.test.ts
• Passed: bunx biome check apps/agent/components/ai-elements/run-result-dialog.tsx apps/agent/entrypoints/app/scheduled-tasks/ScheduledTasksPage.tsx apps/agent/entrypoints/newtab/index/NewTabChat.tsx apps/agent/entrypoints/newtab/index/ScheduleResults.tsx apps/agent/entrypoints/sidepanel/index/useChatSession.ts apps/agent/lib/schedules/scheduledChatContext.ts apps/agent/lib/schedules/scheduledChatContext.test.ts
• Passed: git diff --check origin/dev...HEAD
• Local blocked: bun run typecheck cannot find wxt; tracked as bosmain-090.
• Local blocked: bun run build cannot find graphql-codegen; tracked as bosmain-4xe.

[Nikhil (shadowfax92)]

Refinery rejected this merge request after CI gate. GitHub runner / Typecheck failed with apps/agent/entrypoints/newtab/index/NewTabChat.tsx(200,13): Type 'string' is not assignable to type 'Error'. Source issue bosmain-a0l has been reopened for rework; this branch is not merged.

[github-actions]

✅ Tests passed — 1226/1230

Suite	Passed	Failed	Skipped
✅ agent	83/83	0	0
✅ build	9/9	0	0
✅ eval	93/93	0	0
✅ server-agent	261/261	0	0
✅ server-api	203/203	0	0
✅ server-browser	4/4	0	0
✅ server-integration	9/10	0	1
✅ server-lib	242/242	0	0
✅ server-root	60/63	0	3
✅ server-skills	31/31	0	0
✅ server-tools	231/231	0	0

View workflow run

[greptile-apps]

Greptile Summary

This PR adds a "Continue in Chat" flow for scheduled task results: a new button in RunResultDialog navigates to /home/chat?scheduledRunId=…&mode=chat, where useChatSession loads the run's output from local storage and injects it as background system-prompt context so the user can ask follow-up questions about the result.

• scheduledChatContext.ts is a new utility that formats a ScheduledJobRun (plus optional job metadata) into a structured system-prompt string; returns null when the result is empty.
• useChatSession.ts gains a scheduledRunId URL-param watcher that asynchronously loads context into a ref, exposes a ScheduledTaskContextState discriminated union to the UI, and has a fallback re-fetch path in handleSendMessage for messages sent before the async load completes.
• NewTabChat.tsx now renders a status banner for the loaded context and refactors the initial URL-param cleanup to preserve scheduledRunId and mode while only stripping query-specific params.

Confidence Score: 3/5

The core context-injection path works, but a provider-switch mid-conversation leaves a stale scheduledRunId in the URL that silently re-injects the old run's data into the new conversation without surfacing the banner the user would normally see.

Switching providers while a scheduledRunId param is present triggers resetConversationState (clears the ref and sets status to 'idle') but leaves the URL param untouched. The next send hits the fallback re-fetch branch, injects the old scheduled context into a completely different conversation, and does so with no visible indication to the user — producing surprising or confusing LLM responses.

useChatSession.ts — specifically the interaction between resetConversationState, handleSelectProvider, and the scheduledRunIdParam URL param that survives the reset.

Important Files Changed

Filename	Overview
packages/browseros-agent/apps/agent/entrypoints/sidepanel/index/useChatSession.ts	Core change: adds scheduledRunId URL-param detection, async context loading, and a fallback re-fetch in handleSendMessage. A defect exists: resetConversationState clears the ref but not the URL param, so a provider-switch silently re-injects the stale scheduled context on the next send.
packages/browseros-agent/apps/agent/entrypoints/newtab/index/NewTabChat.tsx	Adds scheduled-context status banner (ready/error) to the chat area; also refactors the initial-URL-param handling to preserve mode and scheduledRunId while only clearing query-specific params. The "ready" banner never self-dismisses once messages are present.
packages/browseros-agent/apps/agent/lib/schedules/scheduledChatContext.ts	New utility that formats a ScheduledJobRun + optional ScheduledJob into a system-prompt string. Logic is straightforward; returns null when result is empty. Well-tested.
packages/browseros-agent/apps/agent/lib/schedules/scheduledChatContext.test.ts	New test file covering the happy path, null-result guard, and missing-job fallback for buildScheduledTaskResultChatContext. Coverage looks adequate for the utility.
packages/browseros-agent/apps/agent/entrypoints/app/scheduled-tasks/ScheduledTasksPage.tsx	Adds handleContinueInChat which navigates to /home/chat?scheduledRunId=…&mode=chat; straightforward and isolated to the scheduled-tasks page.
packages/browseros-agent/apps/agent/entrypoints/newtab/index/ScheduleResults.tsx	Adds the same handleContinueInChat pattern for the new-tab schedule results widget; logic mirrors ScheduledTasksPage cleanly.
packages/browseros-agent/apps/agent/components/ai-elements/run-result-dialog.tsx	Adds optional onContinueInChat prop and a "Continue in Chat" button that is only shown when both a result and the callback are present; minimal and correct.

Comments Outside Diff (1)

1. packages/browseros-agent/apps/agent/entrypoints/sidepanel/index/useChatSession.ts, line 870-882 (link)

   Stale scheduledRunId silently re-injects context after provider switch

   resetConversationState clears scheduledTaskContextRef.current and resets the UI state to 'idle', but it does not remove scheduledRunId from the URL. When a user switches providers mid-conversation, handleSelectProvider calls resetConversationState, the banner disappears (state → 'idle'), yet scheduledRunIdParam is still set. The next sendMessage hits the fallback branch, re-fetches the old run's context, and silently injects it into the new provider's system prompt — all without showing the "Scheduled task result loaded" banner that normally signals this behavior.

   Prompt To Fix With AI

   This is a comment left during a code review.
   Path: packages/browseros-agent/apps/agent/entrypoints/sidepanel/index/useChatSession.ts
   Line: 870-882
   
   Comment:
   **Stale `scheduledRunId` silently re-injects context after provider switch**
   
   `resetConversationState` clears `scheduledTaskContextRef.current` and resets the UI state to `'idle'`, but it does **not** remove `scheduledRunId` from the URL. When a user switches providers mid-conversation, `handleSelectProvider` calls `resetConversationState`, the banner disappears (state → `'idle'`), yet `scheduledRunIdParam` is still set. The next `sendMessage` hits the fallback branch, re-fetches the old run's context, and silently injects it into the new provider's system prompt — all without showing the "Scheduled task result loaded" banner that normally signals this behavior.
   
   How can I resolve this? If you propose a fix, please make it concise.

Prompt To Fix All With AI

Fix the following 3 code review issues. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 3
packages/browseros-agent/apps/agent/entrypoints/sidepanel/index/useChatSession.ts:870-882
**Stale `scheduledRunId` silently re-injects context after provider switch**

`resetConversationState` clears `scheduledTaskContextRef.current` and resets the UI state to `'idle'`, but it does **not** remove `scheduledRunId` from the URL. When a user switches providers mid-conversation, `handleSelectProvider` calls `resetConversationState`, the banner disappears (state → `'idle'`), yet `scheduledRunIdParam` is still set. The next `sendMessage` hits the fallback branch, re-fetches the old run's context, and silently injects it into the new provider's system prompt — all without showing the "Scheduled task result loaded" banner that normally signals this behavior.

### Issue 2 of 3
packages/browseros-agent/apps/agent/entrypoints/newtab/index/NewTabChat.tsx:193-197
**"Scheduled task result loaded" banner persists for the entire conversation**

The `scheduledTaskContext.status === 'ready'` banner renders unconditionally in the scroll area — it never dismisses itself once messages are exchanged. After the user sends their first message the banner continues to float below all chat messages, which may be confusing. Consider hiding it once `messages.length > 0` or after the first send completes.

### Issue 3 of 3
packages/browseros-agent/apps/agent/entrypoints/newtab/index/NewTabChat.tsx:193-203
**No loading indicator while scheduled context is being fetched**

When `scheduledTaskContext.status === 'loading'`, the UI shows the normal empty chat state with no indication that context is being loaded. A user who sends a message immediately after navigating here will trigger the fallback re-fetch path in `handleSendMessage`, but there is no feedback that this happened. Even a small spinner or disabled-send hint next to the existing banner would prevent the silent load-and-inject pattern from being invisible.

_{Reviews (1): Last reviewed commit: "fix: wait for scheduled context before c..." | Re-trigger Greptile}