CI: fail PR when @google/gemini-cli npm tarball exceeds size threshold

## Summary

Add a CI check that fails a PR if the published npm tarball for `@google/gemini-cli` (or `@google/gemini-cli-core`) would exceed a known-safe size threshold. Catches the kind of regression that produced #25507 (an `npm publish` E413 from wombat-dressing-room) **at PR review time** instead of at release time.

## Why is this needed?

The chain that broke `Release: Promote` for ~7 days:

1. PR #25342 added 5 cross-platform `ripgrep` binaries (~21 MB raw) into `bundle/vendor/ripgrep/`.
2. The PR template only asks for "validated on macOS / npm run" (which the author checked). Nothing in the template or CI surfaced the published-tarball size.
3. The change merged.
4. The first nightly to include the change failed with E413 (auto-filed #25507, `priority/p0`, `release-failure` — closed without action).
5. Six subsequent nightlies stalled in the `prod` environment approval queue, silently.
6. Eight days later, a manual `Release: Promote` finally surfaced the failure to a human.

A CI guard at step 2 would have prevented all of this with a single line of red on the PR.

## Proposed plan

Add a job to `.github/workflows/ci.yml` (or a small new workflow that runs on PRs touching `scripts/`, `packages/*/package.json`, `esbuild.config.js`, and anything that changes bundle composition):

```yaml
tarball_size:
name: 'Check npm tarball size'
runs-on: 'gemini-cli-ubuntu-16-core'
needs: 'merge_queue_skipper'
if: "github.repository == 'google-gemini/gemini-cli' && needs.merge_queue_skipper.outputs.skip == 'false'"
steps:
- uses: 'actions/checkout@…'
- uses: 'actions/setup-node@…'
with: { node-version-file: '.nvmrc', cache: 'npm' }
- run: 'npm ci'
- run: 'npm run bundle'
- run: 'node scripts/prepare-npm-release.js'
- name: 'Check @google/gemini-cli tarball size'
run: |
SIZE_BYTES=$(npm pack --dry-run -w @google/gemini-cli --json 2>/dev/null \
| jq -r '.[0].size')
SIZE_MB=$(awk -v b="$SIZE_BYTES" 'BEGIN { printf "%.1f", b/1048576 }')
# wombat-dressing-room's hard limit is somewhere in the 25-28 MB range;
# leave headroom.
LIMIT_MB=22
echo "@google/gemini-cli tarball: ${SIZE_MB} MB (limit ${LIMIT_MB} MB)"
if (( $(echo "$SIZE_MB > $LIMIT_MB" | bc -l) )); then
echo "::error::@google/gemini-cli tarball is ${SIZE_MB} MB — exceeds the ${LIMIT_MB} MB safety threshold for wombat-dressing-room. Consider trimming bundled assets, or moving large native binaries to platform-specific optionalDependencies."
exit 1
fi
- name: 'Check @google/gemini-cli-core tarball size'
run: |
# Same check, lower threshold (core's historical baseline is ~10 MB).
...
```

### Key design decisions

- **Threshold tuning.** Set the limit ~10–15% below the actual wombat ceiling so we get warned before a release fails. Values above (~22 MB for cli, ~15 MB for core) are starting points that match the current healthy baselines from #25841.
- **Run on PRs, not just `main`.** The whole point is to catch this in review, not after merge.
- **Output is actionable.** The error message names the likely fix (move binaries to `optionalDependencies`) so reviewers / authors don't have to reverse-engineer it.
- **Don't gate the merge queue on this if the threshold is hit by a legitimate growth.** The label-bypass pattern (`area/release-known-bigger-tarball` or similar) lets release-aware PRs override after a maintainer reviews.
- **Optional follow-up:** also report the tarball size as a status comment on the PR so authors see the trend even when below the limit.

## Estimated effort

~2–3 hours, including PR template tweak to add a "tarball size impact" item to the bundle-affecting PR checklist.

## Related Issues

- Caused by: #25342 (silently grew the tarball)
- Surfaced via: #25507 (auto-filed nightly failure)
- Mitigated by: #25841 (the actual unblock; doesn't prevent recurrence)

## Additional context

- `npm pack --dry-run --json` provides exact bytes; no parsing of `npm notice` output needed.
- The `bundle_size` job in `.github/workflows/ci.yml` already does diffing for the SEA bundle; this would be its npm-tarball cousin.
- The release-infra check is layered: this CI job catches at PR time; the `Release: Promote` job will still legitimately fail at publish time if someone bypasses the check, so we're not removing the safety net, just adding an earlier one.