CI: scope down Next.js Bundle Analysis workflow and gate it behind a GitHub environment

[josephfusco]

The Next.js Bundle Analysis workflow (.github/workflows/nextjs-bundle-analysis.yml) runs far more often than it needs to, and is not tied to a GitHub environment.

Problem

The analyze job triggers on every pull_request (all branches except main/next) and every push to canary. Each run does a full npm ci, npm run build of the whole monorepo, and a webpack Next.js build of examples/next/faustwp-getting-started, solely to produce a bundle-size comparison comment for that one example app.

This is excessive because it also runs on PRs where the example bundle cannot meaningfully change, e.g.:

• Dependabot dependency-bump PRs
• The automated changeset-release/canary (Version Packages) PRs
• Plugin-only, docs-only, and other unrelated changes

The full monorepo + Next.js build on every one of these is slow and burns CI minutes for no signal.

Current triggers

on:
  pull_request:
    branches-ignore:
      - 'main'
      - 'next'
  push:
    branches:
      - 'canary'
  workflow_dispatch:

The workflow declares no environment:.

Proposed changes

1. Gate the analyze job behind a dedicated GitHub environment (e.g. bundle-analysis), so runs are controllable and any protection rules live in one place — consistent with how the wordpress.org deploy job uses environment: wordpress-org.
2. Add paths: filters so it only triggers when the example app or the packages it bundles actually change (e.g. examples/next/faustwp-getting-started/**, packages/**).
3. Skip automated/bot PRs (Dependabot, changeset-release/*).

Acceptance criteria

• Bundle analysis no longer runs on unrelated or bot-generated PRs.
• It runs only when the example app or its bundled dependencies change.
• The analyze job is gated behind a GitHub environment.