v1.0-rc2

CI: dev staging branch + fast-forward promotion to main (#346) (#375)

* CI: dev staging branch + fast-forward promotion to main (#346)

Part 2 of the dev-staging model. All additive; PR targets dev.

- ci.yml: add `dev` to the push trigger so the full suite runs on dev
  pushes and deploy-web ships --branch=dev (staging alias). Add an
  always-green `ci-passed` aggregate job for the dev ruleset to require,
  since per-path-filtered jobs can't be required directly (a Skipped job
  reads as an unmet check). deploy-web/bench-history stay out of its
  needs — they're post-merge, not merge gates.
- promote.yml: new manual workflow_dispatch that fast-forwards main to
  dev and pushes with a GitHub App token (bypasses main's push
  restriction AND triggers the downstream production deploy, neither of
  which GITHUB_TOKEN can do).
- CONTRIBUTING.md: Branching & release flow section.
- ADR-0055: records the model (0054 was taken by web-chat-agent-host).

Deliberately unchanged: clean-merged-branches.sh (auto-targets the
default branch), gen-share-links.mjs ORIGIN (production by design),
bench-history / perf gate / release.yml (all main-keyed).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01K5ZJkXhNfxfzjtG1QDZhE4

* CI: name the aggregate gate job `ci-passed` so the ruleset can match it

GitHub matches required status checks by a job's `name`, not its id. With
`name: CI passed (aggregate gate)` the check reported under that string, so
the `dev` ruleset (which requires `ci-passed`, per #346/ADR-0055) could
never match it — every PR would block waiting on a check that never
reports. Rename the job's `name` to `ci-passed` so the required-check
string is identical everywhere.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01K5ZJkXhNfxfzjtG1QDZhE4

---------

Co-authored-by: Claude <noreply@anthropic.com>