fix(e2e): drive run_dbconnect notebook cells explicitly after the kernel is bound

[rugpanov]

Summary

Fixes the flaky run_dbconnect.ucws notebook + magic tests. Run All /
Jupyter: Run All Cells runs the first DBConnect cell but doesn't advance to
the rest in the headless CI harness, so later cells stay <not run> and the
expected *-output.json files are never written.

Evidence this is harness-only, not a product bug

• Cell-level diagnostics (test(e2e): capture notebook cell errors in run_dbconnect diagnostics #2013) showed cell 0 success=true, later cells <not run>.
• Manual repro on a real machine (real serverless DBConnect): Run All ran
  both .ipynb cells; running the .py Databricks-notebook cells one-by-one
  through the kernel produced all four output files (hello world, hello; world,
  hello run;). The progress-bar ipywidget was present throughout and did not
  block advancement.

So the auto-advance stall is specific to webdriver/xvfb, not real users. The fix
stays in the test and keeps execution going through VS Code (real kernel + the
extension's injected spark/%sql/_sqldf/%run magics).

What changed

• Add executeNotebookCell(i) / runRemainingActiveNotebookCells() helpers that
  run cells via the VS Code notebook.cell.execute command.
• Only execute cells explicitly AFTER the kernel is bound by the initial
  Run All. (An earlier approach drove cells from the start and hung with
  "Remote command timeout exceeded" — executing a cell with no kernel opens a
  modal kernel picker that never resolves the executeWorkbench promise.)
• Notebook test: Run All → wait for cell 0 output → run cell 1 (%run) explicitly.
• Magic test: Run All Cells → wait until first cell has an executionOrder → run
  remaining cells → assert both %sql→_sqldf and %run outputs.

Verification

• tsc/eslint/prettier clean; esbuild+keepNames shows 0 __name in the callbacks.
• Underlying execution verified working on a real workspace (one-by-one cell run
  produced all outputs).
• End-to-end validation is the databricks-eng e2e run (requires the harness).

This pull request and its description were written by Isaac.

[rugpanov]

🤖 Integration tests triggered for 13f98326 — ⏳ running.
View run

[rugpanov]

🤖 Integration tests ❌ 5 of 35 test jobs failed for 5128b575 (30 passed).
View run

[rugpanov]

🤖 Integration tests ❌ 7 of 35 test jobs failed for baefbfb1 (28 passed).
View run

[rugpanov]

🤖 Integration tests ❌ 7 of 35 test jobs failed for 510d98bc (28 passed).
View run

[github-actions]

If integration tests don't run automatically, an authorized user can run them manually by following the instructions below:

Trigger:
go/deco-tests-run/vscode

Inputs:

• PR number: 2014
• Commit SHA: 03a6b8a865567efd4437e587d611ab787278266c

Checks will be approved automatically on success.

[rugpanov]

🤖 Integration tests ❌ 6 of 35 test jobs failed for 03a6b8a8 (29 passed).
View run

[rugpanov]

Closing in favor of @anton-107's parallel stack (#2019–#2022), which covers the same run_dbconnect flakiness and is further along (#2022 already gets the .ipynb "should run a notebook with dbconnect" test passing).

Sharing what I found while investigating, in case it helps with the one case still failing in both our runs — the magic / Interactive Window test (should run a databricks notebook … handle magic comments):

• Root cause is harness-only. Verified on a real machine + serverless DBConnect: Run All runs all cells, and running cells one-by-one through the kernel produces all four output files (hello world, hello; world, hello run;). The stall (Run All executes the first DBConnect cell then doesn't advance) reproduces only in the headless webdriver/xvfb harness, not for real users. The DBConnect progress-bar ipywidget is present but does not block execution on a real machine.
• The Interactive Window is not window.activeNotebookEditor (the focused editor is the .py text editor). It's in vscode.workspace.notebookDocuments as notebookType === "interactive" — an active-editor-only lookup silently no-ops for it.
• Driving cells explicitly works via notebook.cell.execute with document: doc.uri (URI-based resolution; the command silently returns with no throw if it can't resolve the editor). In my last run the .ipynb cell dispatched correctly (dispatched cells [1]); the remaining issues were (a) awaiting cell completion (not just dispatch) before checking the output file, and (b) the IW execute call hanging ("Remote command timeout exceeded").

Happy to hand over the standalone repro project and the per-cell/IW helper if useful. Deferring to your stack for the actual fix.