docs: add the major-line runbook (fixes #2979)

[mfal]

ADR 0004 §11 says
the next → major cascade uses "the same mechanism" as main → next. That
holds for the design, not for the configuration: every piece of
automation is hardcoded to the two standing lines, so opening 2.x today means
discovering that one broken invariant at a time.

New docs/major-line-runbook.md records what has to happen — the branch and
ruleset (in that order), the guard and workflow edits, the second cascade, the
sync tooling, a verification list for the first PR, and the promotion and
retirement paths. ADR 0004 §11 is expanded in place with the configuration gaps
and points at it; release-workflow.md links it from the model and from Where
to look next.

Decisions recorded

Decision	Value
Branch name	2.x — the routing guard's head-ref exemption already matches it
dist-tag	next-major — next is taken, latest is the stable line
preid	major → 2.0.0-major.N, kept separate so the version string stays readable
Publish workflow	publish.yml, extended — never a second file (npm's Trusted Publisher binds one workflow filename per package; that is what killed the first two next publishes, #2968)

Found while verifying against the code

Everything in the runbook was checked against the actual workflows and scripts
rather than taken from the issue. Four things the issue does not name:

• Escalation cross-talk. forward-merge.yml's close_sync_issue() closes
  every open sync-labelled issue matching in:title "Forward-merge blocked",
  so a healthy main → next run would close the major line's escalation while
  its conflict still stands. open_sync_issue() suppresses in the other
  direction, and forward-merge-drift.yml looks up its blocker with
  gh issue list --label sync and no title filter.
• sync-resolve.cjs is hardcoded to main → next (BRANCH, the fetch and
  merge of origin/main into origin/next, the message, the PR base) — and it
  is the only way out of a conflict, because GitHub does not run the
  .gitattributes merge drivers. It needs --from/--to, which
  /prepare-release already has.
• The commit-guard.yml if: gates must move into the step, not grow a
  literal branch list: the ruleset requires those four contexts, and a job
  skipped by if: is not a reliable reporter for them. version-contract
  already has the right place (steps.gate).
• publish.yml is six edits, not one — including the seed formula in
  Version (next line), which computes ${M}.${m+1}.0-next.0, a minor
  prerelease. The major line needs ${M+1}.0.0-major.0 and --preid major.

Two details worth calling out

• The ruleset deliberately does not require the coverage context.
  coverage.yml triggers on pull_request: branches: [main] only, so on a
  major-line PR the check never reports — and a required context that never
  reports blocks every PR on the line. next's ruleset omits it for the same
  reason.
• The ruleset must come after the branch: like main's and next's it
  carries a creation rule. And it is not a nicety — the repo allows merge
  commits and squash merges repo-wide, so an unprotected line offers both
  buttons. Verified: chore(sync): resolve forward-merge conflict (main into next) #2969's merge commit e25acaaa5 has a single parent, while
  a27c61b51 and 8b76367f0 have two.

Verification

pnpm format:check and pnpm nx test:links docs green; the release-relevance
classifier reads the change as docs-only → no publish.

fixes #2979

🤖 Generated with Claude Code

[github-actions]

Coverage Report for ./packages/components/

Status	Category	Percentage	Covered / Total
🔵	Lines	76%	627 / 825
🔵	Statements	75.91%	643 / 847
🔵	Functions	77.95%	145 / 186
🔵	Branches	66.66%	298 / 447

File Coverage

No changed files found.

Generated in workflow #6393 for commit 6db2aff by the Vitest Coverage Report Action

[github-actions]

🚀 Preview Deployment

Preview environments are ready:

Type	URL
docs	pr-2997.docs.review.flow-components.de
storybook	pr-2997.storybook.review.flow-components.de

Images:

• docs: ghcr.io/mittwald/flow/docs:pr-2997
• storybook: ghcr.io/mittwald/flow/storybook:pr-2997