chore: add a dev integration branch, and make CI actually watch it

[murffious]

Summary

You asked for a dev branch. Creating one is the easy half; this PR is the half that makes it safe.

The trap this avoids

.github/workflows/ci.yml triggered on [main, master] only. A pull request targeting anything else ran no checks at all.

That is not hypothetical in this repository. Ten pull requests once sat open with no checks, every one of them red, and the failures were invisible in the UI until someone ran the jobs locally against each branch. An integration branch that CI does not watch reproduces exactly that, at scale and by design.

So dev goes into the on: lists:

Workflow	Change
ci.yml	push and pull_request now [main, dev]
docs.yml	pull_request now [main, dev]; push unchanged

Deployment is untouched. It is already gated on github.ref == 'refs/heads/main' and a non-pull-request event, so dev builds the docs site and does not publish it. A broken nav entry or dead link fails in review rather than after the merge.

The flow

git switch dev && git pull
git switch -c feat/thing
gh pr create --base dev

main is what ships, dev is where work integrates, hotfixes still go straight to main.

CONTRIBUTING.md gains a Branches section carrying the flow plus the two rules that fall out of the same incident:

• Do not target a feature branch. Stack by rebasing onto dev, not by pointing one pull request at another.
• Run the suite after any rebase. A rebase onto a squash-merged parent applies cleanly and can still break the build, because the parent's history no longer matches its contents. git rebase succeeding is not a green check. This bit us twice this week.

It also says, in the file people actually read before adding a branch: if you add another merge target, add it to both on: lists in the same commit, or you have rebuilt the trap.

Two things to do on merge

1. Create the branch: git switch -c dev main && git push -u origin dev. I have not created it yet, because a dev that predates this commit is a dev with no CI.
2. Turn on delete-branch-on-merge in repository settings. It is currently off, which is why the branch list grew until it needed a manual audit. All eight stale branches turned out to be fully merged ancestors of main.

I can do both once this lands, or you can.

Test plan

Check	Result
Both workflow files parse as YAML	pass
mkdocs build --strict	pass
Deploy step still gated on refs/heads/main	verified unchanged

🤖 Generated with Claude Code