Support `next` branch as long-lived prerelease branch alongside `main`

[data-douser]

Summary

Introduce a long-lived next branch to support -next.N prerelease versioning. The next branch should be treated like main for CI/CD purposes — features are developed on next and merged to main when they are ready to move from prerelease to stable.

Motivation

We need a branching strategy that supports publishing prerelease versions (-next.N suffixed) from a dedicated next branch while keeping main as the stable release branch. Changes from next are merged to main when features are ready to graduate from prerelease status.

Changes Required

GitHub Actions Workflows (.github/workflows/**)

All on.pull_request and on.push triggers that reference main must also reference next. The following 7 workflow files need updates:

Workflow	pull_request	push
lint-and-format.yml	add next	add next
client-integration-tests.yml	add next	add next
query-unit-tests-swift.yml	add next	add next
build-server.yml	add next	add next
query-unit-tests.yml	add next	add next
dependency-review.yml	add next	N/A (no push trigger)
build-and-test-extension.yml	add next	add next

The remaining 7 workflows do not require changes:

• release-tag.yml, release-npm.yml, release-vsix.yml, release-codeql.yml — workflow_call only
• copilot-setup-steps.yml — no branches filter, already runs on all branches
• update-codeql.yml — workflow_dispatch + schedule only
• release.yml — triggers on tags (v*), not branches

Example change (build-server.yml):

# Before
on:
  pull_request:
    branches: ['main']
  push:
    branches: ['main']

# After
on:
  pull_request:
    branches: ['main', 'next']
  push:
    branches: ['main', 'next']

Documentation (docs/**/*.md, *.md)

Consider updating documentation to describe:

• The next branch purpose and lifecycle
• How prerelease versions (-next.N) are published from next
• The merge workflow from next → main for feature graduation
• Branch protection rules for next (if applicable)

Release Workflows

Evaluate whether release-related workflows (release.yml, release-tag.yml, release-npm.yml, release-vsix.yml, release-codeql.yml) need adjustments to support prerelease publishing from next. Currently they trigger on v* tags or workflow_call, which may already work for prerelease tags like v1.2.3-next.1.

Related

• PR ql-mcp-client rewrite: Phases 1 & 2 — Replace ql-mcp-client.js with Go implementation #223 (dd/ql-mcp-client/2 branch) will be rebased to next once this branching strategy is in place
• PR Improve ql-mcp VS Code extension UX #230 (current copilot/improve-vscode-extension-ux work)