ci: stop committing versions to master on merge (--no-bitmap-commit + bitmapAutoSync)

[davidfirst]

Draft — the core change that lets bit_merge stop pushing commits to master, which is the prerequisite for enabling the GitHub merge queue. Do not merge until the two prerequisites below are met.

What it does

• bit ci merge --no-bitmap-commit — after tag/export, no git add/commit/push to the default branch. New component versions live only in the scope.
• bitmapAutoSync: true (workspace.jsonc) — every command on the main lane reconciles the local .bitmap from the latest exported scope HEAD, so a "stale" committed .bitmap self-corrects at runtime. The scope becomes the single source of truth for versions, replacing the old post-merge bump commit.
• Removes bit_merge's generate-cli-reference* / generate-core-aspects-ids steps — they're now verified and committed in PRs by check_generated_reference (ci: verify generated CLI-reference files are committed in the PR #10428), and --no-bitmap-commit would discard their output anyway.

Why

Today every merge pushes a .bitmap version-bump commit to master. That commit is the thing the next PR must consume (or collide on), and it's a post-merge mutation the merge queue can't coordinate with. Removing it dissolves both the existing inter-PR version race and the merge-queue blocker. The existing serial-group: bit-merge-operations remains the interlock that prevents two concurrent exports minting the same version.

Prerequisites before this can merge

1. Bake check_generated_reference (currently advisory) on real PR traffic — confirm it doesn't go red on PRs that don't touch the CLI (that would signal nightly bit-version drift; we'd pin the generation version before requiring it).
2. Promote check_generated_reference to a required check at merge time. This PR removes the post-merge generation safety net, so the PR check becomes the sole guarantee the reference stays current — it must block.

Known consequences (by design)

• .bitmap and pnpm-lock.yaml are no longer auto-committed to master post-merge; PRs carry their own changes and bitmapAutoSync reconciles versions. mergePr already checks out with skipNpmInstall, so it wasn't meaningfully updating the lockfile anyway.
• The committed .bitmap on master will intentionally lag the scope; this is reconciled per-workspace at runtime.

Rollout note

Recommend merging this and letting master merges run on it for a while (verify exports still land and bitmapAutoSync logs synced N component(s)) before the CircleCI gh-readonly-queue.* allowlist + enabling the queue, so the version-decoupling is validated independently of the queue switch.