feat(workbench): run session-launch tests under --api-auth when a Workbench API token is provided

Summary

When --api-auth is used, every @workbench test is deselected — including tests that could run against the Workbench API with an admin/super-admin token. --api-auth keeps only tests marked @api_auth, and no Workbench feature file carries that marker (only the nine Connect feature files do). The plumbing to authenticate a WorkbenchClient with an API key already exists (VIP_WORKBENCH_API_KEY → WorkbenchConfig.api_key → WorkbenchClient(api_key=...)), but nothing exercises it under --api-auth.

This is the Workbench analog of #222 (the Connect --no-auth/API-key gap), which was resolved for Connect but never extended to Workbench.

Why this matters

A common customer situation: Workbench is behind SSO that can't be scripted, and interactive/headless browser auth isn't available on the testing host, but the admin can mint a Workbench API token. Today VIP gives those users zero Workbench coverage. At minimum, an API token should let VIP verify that the relevant session types can be launched and reach an active state — the single most important Workbench capability check.

Root cause

• src/vip/plugin.py:509 — _AUTH_PRODUCTS = {"connect", "workbench"}, so every @workbench test is "auth-requiring".
• src/vip/plugin.py:401 — under --api-auth, any auth-requiring test that is not @api_auth-marked is deselected.
• grep -rln api_auth src/vip_tests/workbench/ → no matches. All session/IDE/job tests are Playwright/UI-driven (test_ide_launch.py, test_session_capacity.py, etc.), keyed off a browser storage-state session, with no API-key launch path.

So --api-auth + a valid VIP_WORKBENCH_API_KEY runs no Workbench tests at all.

Important nuance from the Workbench API docs

I checked the official Workbench API docs. Two things the implementation must account for — the current WorkbenchClient does not match either:

1. Auth scheme. The Workbench API uses API tokens as Authorization: Bearer <token>, generated server-side with rstudio-server generate-api-token <user|admin|super-admin> <name> <username>. These are not Connect API keys. But WorkbenchClient currently sends Authorization: Key <api_key> (src/vip/clients/workbench.py:48) — Connect's scheme. An API-key launch path needs the Bearer scheme.

2. Token privilege for launching.

   • user token → launch/query/suspend/stop own sessions.
   • admin token → read metadata + stop/suspend any user's sessions, but cannot launch.
   • super-admin token → full access, including launch_session on behalf of a user.

   So a session-launch test via the API needs a super-admin (or user) token, not merely admin. The API is also only available on the Enhanced/Advanced Workbench tiers.

3. Endpoint set. The documented admin API is POST /api/launch_session, POST /api/get_session, POST /api/stop_session, POST /api/resume_session, POST /api/launch_job, GET /api/get_compute_envs, GET /api/version. The current WorkbenchClient instead talks to the UI-facing /api/sessions, /api/sessions/{id} (DELETE/suspend) and /api/server/settings endpoints, which are cookie-authenticated. Adding API-token launch coverage likely means teaching the client the documented /api/launch_session + /api/get_session methods.

Docs: https://docs.posit.co/ide/server-pro/admin/workbench_api/workbench_api.html and https://docs.posit.co/ide/server-pro/admin/workbench_api/interface.html

Tests that are good candidates for an API-token path

Reviewing src/vip_tests/workbench/, these map cleanly onto the documented API and would be the highest-value additions:

Session cleanup already works over the API (quit_vip_sessions), so the teardown side is in place.

Suggested direction

1. Add an @api_auth marker to the Workbench scenarios that can be driven purely via the API token (starting with IDE launch and session capacity).
2. Give WorkbenchClient a Bearer-token auth path and launch_session/get_session/stop_session methods, selected when an API token is configured.
3. Document that Workbench API-token testing requires a super-admin (or user) token on an Enhanced/Advanced deployment, and that admin tokens cannot launch sessions.
4. As with #222, --api-auth should then run these Workbench tests instead of deselecting the entire product.

Key files

• src/vip/plugin.py:401,509 — --api-auth deselection + _AUTH_PRODUCTS
• src/vip/clients/workbench.py:48 — Authorization: Key header (needs a Bearer path)
• src/vip_tests/workbench/test_ide_launch.py, test_session_capacity.py — UI-only launch today
• src/vip/config.py:266 — VIP_WORKBENCH_API_KEY already wired