Implement branch-per-SPFx-version strategy

[nick-pape]

Summary

The dev design states: "We will have a branch for every SPFx release type (including beta, rc). The CLI tool constructs the URL assuming the SPFx version is a branch in the repo. Main is always latest."

This branching strategy is not yet implemented — everything currently lives on `main`.

Requirements

Branch naming

SPFx Version	Branch Name
Latest stable	`main`
1.22.2	`release/1.22.2` (or `1.22.2`)
1.23.0-beta.1	`release/1.23.0-beta.1` (or `1.23.0-beta.1`)
1.23.0-rc.1	`release/1.23.0-rc.1` (or `1.23.0-rc.1`)

Workflow

1. New SPFx release: create a branch from `main`, update `spfxVersion` in all `template.json` files, regenerate examples
2. Hotfix to old version: cherry-pick fix to affected release branches
3. `main` always tracks latest stable: after creating a release branch, `main` continues forward

CLI integration

• `PublicGitHubRepositorySource` already accepts a `branch` parameter
• `--spfx-version 1.22.0` → GitHub source uses branch `release/1.22.0`
• URL pattern: `https://codeload.github.com/{owner}/{repo}/zip/release/{version}\`

Branch protection

• Release branches should have branch protection rules
• Require PR reviews for changes to release branches
• CI must pass before merge

Automation considerations

• Consider a GitHub Action that auto-creates release branches when a new SPFx version is detected
• Consider a script/workflow for cherry-picking security fixes across active release branches
• Document which release branches are actively maintained

Dependencies

• `--spfx-version` flag (Add --spfx-version flag to create command #92) uses this branching strategy

Acceptance criteria

• Branch naming convention is documented
• Process for creating release branches is documented
• CLI correctly maps `--spfx-version` to branch names
• Branch protection rules are configured for release branches
• Cherry-pick workflow is documented for hotfixes