Adopt GitFlow, and document CI and releasing under docs/

[ChrisonSimtian]

Moves the repo from a single trunk to GitFlow as originally defined, plus long-lived support/* lines because the extension has to keep serving Fallout release lines that main has moved past.

Branch	Role
develop	integration trunk, and the new default branch
main	production; only release/hotfix merges, each tagged
release/*	stabilisation window: develop → main → back to develop
hotfix/*	urgent production fix: main → main → develop
support/vX.Y	maintenance line for an older Fallout line, cut on demand

Why support/* and not release/vX.Y

In GitFlow the release/* prefix already means the temporary stabilisation branch. Using it for a long-lived maintenance line makes every sentence about "the release branch" ambiguous. support/* is what the git-flow AVH tooling calls it, and what Fallout calls it.

Wiring

• build.yml regenerated from the attribute to gate PRs into develop, main and support/*. build-skip.yml mirrors that branch list, as it already mirrors the job name and the inverse path set.
• preview.yml moves to push-on-develop. main only receives tagged release merges, so a preview build of main would duplicate a release build of the same commit.
• publish.yml's validate-ref now accepts main and support/vX.Y, and rejects develop — under GitFlow the trunk is never tagged for release.
• version.json's publicReleaseRefSpec covers every branch that can produce a distributable build, so nbgv get-version stays honest before tagging.

Docs

Three docs under docs/, with mermaid diagrams — all six validated by rendering them through mermaid-cli, not by eyeballing the syntax:

• branching-and-release.md — the model, a gitGraph of the full flow, and a decision tree for which branch a given fix belongs on.
• ci.md — what runs when, the generated-vs-hand-written split and why, and the required-check/paths-ignore trap that build-skip.yml exists for.
• releasing.md — versioning, channels, and a runbook per release kind (simple, stabilised, RC, hotfix, support line, promotion).

RELEASING.md is removed in favour of docs/releasing.md. README points at the new set and states the contribution flow. .vscodeignore excludes docs/** so none of it ships in the .vsix.

Two frictions documented rather than papered over

Both come from GitFlow meeting this repo's linear-history rule:

1. develop → main wants a rebase merge, not a squash. Squashing collapses an entire release into one commit on the production branch.
2. "Merge back to develop" is necessarily a cherry-pick or a second PR, since merge commits are disabled. The effect still has to happen — a hotfix that never reaches the trunk ships once and then vanishes on the next release.

Note on sequencing

This PR targets main, not develop, and it's the last one that will. develop doesn't exist yet: if I'd created it first, a PR into it would have run no gate at all — build.yml currently only triggers on PRs to main — and develop's protection would then block forever on a check that never arrives. This PR is what teaches CI about develop.

After merge: create develop from main, make it default, and apply main's protection profile to it.

🤖 Generated with Claude Code