fix(workspace): branch-aware --ui job, roll back sandbox config on failed create (#755)

[padak]

What

kbagent workspace create --ui failed in every combination reported in #755 and left an orphaned keboola.sandboxes config behind each attempt. This PR fixes what kbagent can fix and makes the rest honest.

1. Dev branch: Queue 400 Cannot resolve job parameters: Configuration ... not found

The sandbox config was created in the pinned dev branch (step 1), but the Queue job was created without branchId, so the Queue looked for the config on the default branch. The job is now queued on the resolved branch, and the follow-up list_config_workspaces uses that same branch instead of int(job["branchId"]) (which is null on the default branch -- a latent TypeError on the same line).

2. Main branch: green job, WORKSPACE_NOT_FOUND

Root cause is server-side and not fixable here: the keboola.sandboxes component removed Snowflake/BigQuery workspace provisioning on 2026-03-26 (keboola/sandboxes@53e1b7e9, "refactor: remove SQL workspace support" -- WorkspaceManager.php deleted). Its create task now only registers a sandbox-service record (POST /sandboxes) and writes parameters.id back into the config; no Storage workspace is created and the job still reports success. The Keboola UI creates SQL workspaces through SQL Editor sessions (editor service, POST /sql/sessions) -- apps/kbc-ui/.../sandboxes/Actions.tsx routes supportSessions(type) (snowflake/bigquery) to createSession, never to the job. The WORKSPACE_NOT_FOUND message now names the job, explains why nothing is attached, and says not to retry (it is not a provisioning race).

The job is deliberately still queued rather than refused up front: a BYOC/private stack running an older keboola.sandboxes image may still provision SQL workspaces through it.

3. Rollback (both modes)

Whenever step 2 (Storage workspace / Queue job) fails, the sandbox config from step 1 is moved to the trash (config restore-able), for headless and --ui alike. The original error is annotated -- message + details: sandbox_config_id, sandbox_config_rolled_back, branch_id, and job_id for --ui. A failed cleanup is reported (sandbox_config_rolled_back: false, sandbox_config_cleanup_error) with the exact config delete to run; it never masks the triggering failure. The command layer forwards details into the --json error envelope.

Docs (silent-drift surfaces)

gotchas.md (new entry, since vNEXT), workspace-workflow.md Option C, commands-reference.md, context.py AGENT_CONTEXT, CLAUDE.md command list, --ui option help.

How it was tested

• 7 new unit tests (tests/test_workspace_service.py::TestCreateWorkspaceUiMode, tests/test_workspace_cli.py): branchId forwarded on dev and default branch, null branchId echo tolerated, rollback on no-workspace / on Queue rejection / on headless failure, cleanup failure surfaced not swallowed, --json details envelope.
• make check green (6576 passed).
• Live A/B on project 6016 (Snowflake, storage-branches on) against the installed 0.93.1:
  • main: 0.93.1 -> green job, orphan config left live (reproduced 1:1 incl. parameters.id = sandbox-service id, no Storage workspace); branch build -> same green job, config in the trash, details.sandbox_config_rolled_back: true.
  • dev branch: 0.93.1 -> the reported 400; branch build -> job runs on the dev branch (400 gone), honest WORKSPACE_NOT_FOUND, config trashed.
  • headless create/delete still works on both branches. Temporary branch and all configs cleaned up afterwards.

Not in this PR (product decision)

Restoring a working --ui means driving the SQL Editor session API (POST /sql/sessions -> poll status: ready -> workspaceId / /credentials): a new HTTP client for the editor service plus session-aware list/delete. Alternatively deprecate --ui. Either way it is a separate decision; suggested fix 4 in the issue (workspace gc detecting config-without-workspace) is also left out since this PR stops that debris from being created in the first place.

Fixes #755