fix(workbench): session launch tests fail with SAML/Okta auth — login not shared from interactive auth

Context

During a VIP verification call with Intuitive Surgical (2026-05-14), all Workbench IDE session launch tests (test_launch_rstudio, test_launch_vscode, test_launch_jupyter) failed with "login failed" errors on both their Workbench 2023 and Workbench 2026 instances.

Their environment:

• AWS EKS deployment
• SAML authentication via Okta
• ALB in front of each product (separate ALBs for Connect and Workbench)
• Interactive auth (--interactive-auth) was used

Connect tests passed (content publishing worked for all types), but the interactive auth session captured during Connect login did not carry over to Workbench.

Root Cause (Suspected)

workbench_login() in src/vip_tests/workbench/conftest.py:110 skips when auth_provider != "password" and there's no pre-loaded session. When --interactive-auth IS used, the storage state is captured from the Connect auth flow, but the SAML session cookie is scoped to the Connect hostname — it doesn't authenticate Workbench on a separate ALB/hostname.

The code at line 126-129 explicitly handles this case:

pytest.skip(
    "Interactive auth storage state did not authenticate Workbench. "
    "The OIDC session may not be shared between Connect and Workbench."
)

But the test reports "login failed" rather than gracefully handling the separate auth domain.

What the Customer Saw

FAILED test_launch_rstudio - login failed
FAILED test_launch_vscode - login failed  
FAILED test_launch_jupyter - login failed

With --verbose, no additional actionable trace was produced beyond the login failure.

Expected Behavior

When interactive auth is used and the products are on separate auth domains (common with ALB + SAML setups), VIP should either:

1. Prompt for a separate Workbench interactive auth session, or
2. Attempt to use the same IdP session cookies (if the IdP domain is shared even when product domains differ), or
3. Provide a clear skip message explaining that Workbench requires its own auth session

Reproduction

• Deploy Workbench behind a separate ALB from Connect
• Configure SAML (Okta) auth
• Run vip verify --workbench-url <url> --interactive-auth
• Observe that the interactive auth captured for Connect does not authenticate Workbench

Additional Context

• Gong call recording: https://us-1237.app.gong.io/call?id=348267831445141666
• Customer offered to email full verbose trace stack output
• Sam suspects the specific issue is SAML vs OIDC handling — VIP may be "looking for the wrong thing when it comes to logging in" for SAML providers
• The 2023 Workbench failures were initially attributed to UI version differences, but the same failure occurred on 2026, confirming it's an auth issue not a selector issue

Start in src/vip_tests/workbench/conftest.py around workbench_login() at lines 110 and 126-129, then run test_launch_rstudio, test_launch_vscode, and test_launch_jupyter with --interactive-auth. Compare the Connect and Workbench storage-state handling during the separate-ALB SAML/Okta reproduction. Done means the tests either obtain the needed Workbench authentication or report a clear, intentional skip instead of a generic login failure.