ci: turn on and fix ui-style and test-vscode stages

[tripleaceme]

Description

Closes #6004.

ui-style and test-vscode were both pinned to if: false. This turns them back on and fixes everything that surfaced once they ran.

1. Formatting / lint drift. With ui-style off, prettier --check . and the per-package eslint runs stopped being enforced, so a few things drifted on main:

• prettier --check . fails on .devcontainer/devcontainer.json, web/client/src/library/components/graph/help.ts, web/client/src/library/components/graph/ModelNode.tsx, and .github/workflows/pr.yaml itself. All reformatted; the changes are whitespace only.
• eslint src tests fails in vscode/extension: tests/lineage_settings.spec.ts imports FrameLocator and Page directly from @playwright/test, which no-restricted-imports forbids for tests/**/*.spec.ts. Every other spec takes Page from ./fixtures, so I followed that convention — re-exported FrameLocator from tests/fixtures.ts and imported both from there.

2. Turning the jobs on, following #5994:

• Added a vscode output to the changes job, filtering on vscode/**.
• ui-style now runs when client, vscode or ci changed, or on main.
• test-vscode gets the same treatment plus the needs: changes it was missing.

test-vscode-e2e is deliberately left disabled, per the note on the issue that its flakiness should be tracked separately.

Note on the pr.yaml diff

Prettier reflows two matrix lists in pr.yaml that grew past the 80-column limit while the job was off — the engine list (StarRocks, #5832) and the dbt-version list (#6028, #5999). Those were already failing prettier --check on main, so they have to be fixed here for fmt:check to go green. I kept them in the CI commit so the formatting-only commit stays reviewable on its own.

Test Plan

Ran both job commands locally against a clean pnpm install:

$ pnpm run lint     # the ui-style job
exit 0

$ PLAYWRIGHT_SKIP_BROWSER_DOWNLOAD=1 pnpm run ci   # the test-vscode job
exit 0

pnpm run ci covers vscode/bus (tsc --noEmit), vscode/extension (eslint + check-types + esbuild + vitest run — 7 tests pass), and web/common (syncpack + eslint + build). Verified it leaves no modified files behind, which matters because web/common's lint script runs with --fix.

I also confirmed against an unmodified upstream/main checkout that the two pr.yaml matrix reflows and the three other unformatted files are pre-existing, not something my edits introduced.

Local run was macOS / Node 24; CI uses Ubuntu / Node 22. Conveniently this PR touches both .github/** and vscode/**, so it should exercise ui-style and test-vscode on itself.

Checklist

• I have run make style and fixed any issues
• I have added tests for my changes (if applicable) — no new tests; this is CI config plus formatting
• All existing tests pass — ran the JS/TS suites via pnpm run ci (see Test Plan). No Python changed, so make fast-test is untouched by this PR and I did not run it
• My commits are signed off (git commit -s) per the DCO

[cmgoffena13]

Looks good to me, thanks for getting to this so fast! -- Trino / Spark failures are separate issue addressed here: #6055

[tripleaceme]

@cmgoffena13

Thanks for the quick review and merge!

Is there anything you'd like me pick up next? I've been digging through the VSCode Extension issues and a few look
tractable:

• Investigate constant crashes to SQLMesh VSCode Extension #5920 and SQLMesh extension clashes with running sqlmesh in terminal #5642 look like the same root cause: extension.ts calls restartLsp() on every onDidChangePythonInterpreter without checking whether the path actually changed, so using the terminal triggers a
  restart storm.
• VSCode Extension: SQLMesh LSP crashes on startup: ImportError: cannot import name 'WorkspaceDiagnosticRefreshRequest' with lsprotocol 2025.x #5768 doesn't look like a dependency pin — pygls already pins lsprotocol exactly, so the real problem is the LSP not being compatible with pygls 2.x. Seems like a small migration (a few import moves and two renamed request types).
• JSON-RPC communication issue between the SQLMesh LSP server and VSCode while using dbt #5457 looks like server.start_io() being called without shielding sys.stdout, so dbt/project log output corrupts the JSON-RPC stream.

Happy to take whichever is most useful, or something else entirely if those are already spoken for or blocked on the extension CI.

[cmgoffena13]

Hey @tripleaceme -- we don't have many working on the Extension side of things rn, just make sure to double check the Issues for any assignees or linked PRs. I think #5920 and is a pretty big win if you want to tackle that one!

[tripleaceme]

I'd like to take this one and I think #5642 is the same bug, so I'll cover both in a single PR.

[cmgoffena13]

@tripleaceme please comment on the appropriate issues for visibility so they can be assigned