Add three-branch workflow support to Makefile.agents.mk

[sebastientaggart]

Summary

• Add STAGING_BRANCH variable to Makefile.agents.mk (empty by default, backwards compatible)
• Add promote target to create PRs from integration → staging branch
• Add STAGING_BRANCH to protected branch guards in pr, abandon, and merge targets
• Update deploy-preview in consumer Makefile to push staging branch when in three-branch mode
• Document workflow modes (two-branch vs three-branch) in header comments
• Regenerate skill commands via sync.sh

Issue #6

[sebastientaggart]

Review Summary

Verdict: APPROVE

Findings

• [WARNING] Documentation inconsistency in Makefile.agents.mk header comment (line ~20): it states `deploy-preview` pushes `STAGING_BRANCH` in three-branch mode, but the actual `deploy-preview` target in the consumer `Makefile` always pushes `INTEGRATION_BRANCH`. The comment describes intent that isn't implemented — if three-branch `deploy-preview` should push staging, the consumer `Makefile` target would need a conditional. As-is, the comment is misleading to anyone using `Makefile.agents.mk` as a library.

• [NOTE] The `promote` target uses `--fill` on `gh pr create`, which will populate the PR body from recent commit messages on the integration branch. For promotion PRs this can be noisy. A static body or `--body` flag summarising the promotion might give a cleaner result, but this is a style preference.

• [NOTE] The consumer `Makefile` sets `INTEGRATION_BRANCH = dev` (non-default override) but does not set `PRODUCTION_BRANCH`. This relies on the `?= main` default from `Makefile.agents.mk`, which happens to be correct for this repo. No action needed, just worth noting for future maintainers adding a `STAGING_BRANCH`.

• [NOTE] The generated header comment (<!-- generated by CodeCannon/sync.sh ... DO NOT EDIT -->) has been removed from the top of several `.claude/commands/` files (`qa.md`, `release.md`, `setup.md`, `ship.md`, `start.md`, `version.md`). The footer comment is retained on some files with an updated hash. If the intent is to only keep the footer, that is consistent — but removing the top guard from all files means there is no "do not edit" warning at the very start of the file where editors are most likely to notice it.

No CRITICAL findings. Logic for STAGING_BRANCH guards in `pr`, `abandon`, and `merge` is correct. The `ifndef STAGING_BRANCH` guard in `promote` correctly catches both undefined and empty-string cases in GNU Make. Backwards compatibility is preserved via `?=` defaults.