Add Positron API integration tests and CI workflow

[jonvanausdeln]

Summary

Fixes posit-dev/positron#14964

Adds a Positron-only integration test suite that runs the Shiny extension inside a real Positron build via @posit-dev/positron-test-electron, plus a CI workflow that runs it on every PR and push to main.

Part of the rollout tracked in posit-dev/positron#14531 (pattern established in quarto-dev/quarto#1058 and posit-dev/publisher#4298).

What's covered

The starter tests (src/test/positron/) exercise the extension's real Positron API surface — code paths unreachable by the plain VS Code suite:

• extension.test.ts — Positron injects the acquirePositronApi global, the extension's own feature detection (isPositron() / getIdeName() in src/extension-api-utils/extensionHost.ts) recognizes Positron, and posit.shiny activates in the Positron extension host.
• run-app-api.test.ts — getPositronRunAppApi() resolves the bundled positron-run-app extension with runApplicationInConsole — the exact gate rRunApp() uses to decide between running R apps in Positron's console vs. a terminal.
• viewer-preview.test.ts — PreviewSourceType.Terminal is exposed with the wire value the extension's fallback hardcodes, and a live previewUrl() round-trip returns a Viewer panel, mirroring openBrowser().

Harness

• scripts/run-positron-tests.mjs downloads/caches a Positron build (stable by default, POSITRON_CHANNEL=daily supported) and runs the Mocha entry point (src/test/positron/index.ts) inside it. Bundled extensions stay enabled because the tests exercise positron-run-app.
• Run locally with npm run test-positron (macOS only for now — an upstream positron-test-electron limitation; Windows/Linux follow once extractable archives are published).
• The plain suite runner now ignores out/test/positron/ so npm test doesn't pick up Positron-only tests in vanilla VS Code.
• src/test/positron/README.md documents how to run and add tests.

CI

.github/workflows/positron-api-tests.yaml — macos-latest, launched through posit-dev/setup-positron, with a date-keyed cache of the Positron download. Runs on PRs and pushes to main.

Found by the new tests: PreviewSourceType drift

The first CI run caught real API drift: the vendored typings (src/types/positron.d.ts) declared PreviewSourceType as a numeric enum (Terminal = 2), but Positron has shipped it as a string enum (Terminal = 'terminal') since before this extension's minimum supported version (2025.12.0). Runtime behavior was accidentally correct (the live enum value is passed through), but getPreviewSourceTypeTerminal()'s declared return type was wrong and buildPreviewSource()'s hardcoded fallback (2) would have sent Positron an invalid value if it ever fired. Fixed by syncing the vendored enum with upstream, correcting the return type, and changing the fallback to 'terminal'; the test now pins the wire value so future drift is caught again. (failing run → green run)

Drive-by fixes: the plain npm test suite was silently broken

Since the esbuild migration, npm test always exited 0 without running anything meaningful:

• import * as Mocha + new Mocha() throws "Mocha is not a constructor" under esbuild's ESM interop → now import Mocha = require("mocha").
• The runner fired mocha.run() without awaiting it, so the extension host exited before any results and failures could never fail the run → now wrapped in a promise.
• With results actually reported, the StreamingTagParser test turned out to be stale (asserts on a boolean return from process(), which is now async/void with results via contentHandler) — skipped with a comment pending a rewrite against the current API.

Testing

• All 7 Positron tests pass on CI inside a live Positron: run 29868140475 (7 passing, 5s)
• npm test (vanilla VS Code suite) passes locally on Windows with the Positron tests excluded
• tsc, ESLint, and Prettier clean