Docker workspace panel shows wrong URL causing trust dialog (regression from 540fc5a78)

[karlorz]

Describe the bug
When clicking "Expand panel" on the Workspace panel in the main task page for Docker-based tasks, the embedded VS Code iframe loads from the wrong URL (serve-web proxy at port 39401) instead of the direct Docker container URL. This causes a workspace trust dialog to appear because the proxy URL doesn't resolve correctly.

To Reproduce
Steps to reproduce the behavior:

1. Create a new task with Docker workspace (not local workspace with provider: 'other')
2. Wait for the Docker container to start and workspace to load in the small panel (this works correctly)
3. Navigate to the main task page (e.g., /dev/task/{taskId}?runId={runId})
4. Click on "Expand panel" button in the Workspace panel header
5. Observe that the expanded iframe shows a workspace trust dialog with "工作區不存在" (Workspace doesn't exist)

Expected behavior
The expanded workspace panel should load the VS Code instance from the direct Docker container URL (e.g., http://localhost:32771/?folder=/root/workspace), just like it does in:

• The small workspace panel before expansion
• The dedicated /vscode route (/dev/task/{taskId}/run/{runId}/vscode)

Screenshots
When clicking "Expand panel", the iframe loads:

• Wrong: http://localhost:39401/?folder=/root/workspace (serve-web proxy)
• Expected: http://localhost:32771/?folder=/root/workspace (direct Docker URL)

The serve-web proxy (port 39401) should only be used for local workspaces (provider: "other"), not Docker workspaces.

Root Cause Analysis
This is a regression introduced in commit 540fc5a78 (Nov 10, 2025).

Timeline:

1. ✅ Nov 7, 2025 - Commit 815e783bd by @lawrencecchen correctly fixed this issue by adding isLocalWorkspace parameter to toProxyWorkspaceUrl()
2. ❌ Nov 10, 2025 - Commit 540fc5a78 accidentally removed the fix from the main task page when adding preloading functionality

Code Location:
apps/client/src/routes/_layout..task..index.tsx around line 475-478

What Happened:
The commit removed the third parameter from toProxyWorkspaceUrl():

// Before (815e783bd - correct)
const workspaceUrl = rawWorkspaceUrl
  ? toProxyWorkspaceUrl(rawWorkspaceUrl, localServeWeb.data?.baseUrl, selectedRun?.vscode?.provider === "other")
  : null;

// After (540fc5a78 - broken)
const workspaceUrl = rawWorkspaceUrl
  ? toProxyWorkspaceUrl(rawWorkspaceUrl, localServeWeb.data?.baseUrl)  // Missing 3rd parameter!
  : null;

Impact:

• ✅ Dedicated /vscode route still works (fix preserved)
• ❌ Main task page workspace panel broken when expanded
• ❌ Affects all Docker-based tasks (most common use case)

Related Work:

• Original fix: 815e783bd - "we have 3 types of vscode urls: 1) cloud tasks 2) local t..."
• Regression: 540fc5a78 - "for the panels page, aka the main page, I want us to prel..."
• Related PR: Fix local task workspace path handling #879 "Fix local task workspace path handling" (different but related issue)

Desktop (please complete the following information):

• OS: macOS 15.3 (Sequoia)
• Browser: Chrome/Firefox
• Version: Latest

Additional context
The fix should restore the provider check that was accidentally removed. The workspace URL should only be proxied for local workspaces (provider: "other"), not for Docker workspaces.

Proposed Solution:

const rawWorkspaceUrl = selectedRun?.vscode?.workspaceUrl ?? null;
const isLocalWorkspace = selectedRun?.vscode?.provider === "other";
const workspaceUrl = rawWorkspaceUrl
  ? isLocalWorkspace
    ? toProxyWorkspaceUrl(rawWorkspaceUrl, localServeWeb.data?.baseUrl)
    : rawWorkspaceUrl
  : null;