Sync main (split PRs wp-graphql#3877/wp-graphql#3878/wp-graphql#3879 + asset pipeline wp-graphql#3880/wp-graphql#3882/wp-graphql#3883) onto
the IDE rebuild branch, on top of Joe's floor/CI commits (floor 6.1, WP 7.0 CI
coverage + tested-up-to). Conflicts (all IDE release metadata) resolved as:

- Version / Stable tag / package.json: 4.5.0 (release-please manifest value;
  release-please bumps to 5.0.0 at release — in-repo version tracks last release
  per the plugin's CLAUDE.md).
- CHANGELOG.md / readme.txt changelog: union — keep the 5.0.0 notes AND main's
  released 4.5.0 entry. Dropped the now-inaccurate "raised floor to 7.0"
  breaking-change note (Joe set the floor to 6.1) and the 7.0-floor framing in
  the i18n docs.
- Requires at least: 6.1 / Tested up to: 7.0 — kept Joe's values.

…blocks)

… longer blocks)"

This reverts commit 08d0977.

The IDE's `codeception.dist.yml` boots Smart Cache via WPLoader's
`plugins:` list. Smart Cache's entry file only loads its classes when
its own `vendor/autoload.php` is present:

  if ( file_exists( __DIR__ . '/vendor/autoload.php' ) ) {
      require __DIR__ . '/vendor/autoload.php';
  }

The reusable workflow ran `composer install` for the plugin under test
and (conditionally) for `plugins/wp-graphql`, but never for
`plugins/wp-graphql-smart-cache`. So inside the test container:

  1. Smart Cache's `Document` class never autoloaded.
  2. `can_load_plugin()` returned false (Document::class missing).
  3. Smart Cache's `init` callback bailed -> `graphql_document` post
     type was never registered.
  4. `SmartCacheBridge::register()` also bailed on the same
     `class_exists` guard, so `show_in_rest` was never filtered on.
  5. Every `/wp/v2/graphql_document/*` REST test 404'd; every
     `graphqlDocument` GraphQL query returned `{errors: ...}` with no
     `data` key (17 failures + 9 errors per matrix row).

The CI band-aids on the branch (re-activating the IDE plugin against
`tests-cli` before the WPUnit suite) were not the fix — WPLoader
bootstraps its own in-process WordPress and doesn't read the
`tests-cli` container's `active_plugins` option.

Mirror the existing `install_wp_graphql_core_deps` pattern: add an
`install_wp_graphql_smart_cache_deps` input to the reusable workflow,
add a conditional composer-install step for Smart Cache, and pass
`true` from the IDE caller.

Same root cause as 877b5c7, but in the JS E2E reusable workflow.

`.wp-env.json` mounts wp-graphql-smart-cache for every plugin's test
container, and Smart Cache's entry file only loads its classes when
its own vendor/autoload.php is present. The E2E reusable workflow
already follows this pattern for wp-graphql core (auto-install for any
plugin that isn't wp-graphql itself) — extend it to Smart Cache.

Without this, Smart Cache's post types + GraphQL types
(`graphql_document`, `graphqlDocumentGroups`, …) never register and
the IDE's e2e suite fails with `Cannot query field "graphqlDocumentGroups"
on type "RootQuery"` on first render.

The endpoint-mode e2e suite toggled the public-endpoint setting with:

  wp option patch update graphql_ide_settings graphql_ide_public_endpoint $value
  || wp option patch insert graphql_ide_settings graphql_ide_public_endpoint $value

`wp option patch` requires the option to exist as a serialized array.
On a fresh tests-cli container the option is missing (or coerced to an
empty string by WordPress internals when no settings have been saved),
so `patch insert` errors with:

  Cannot create key "graphql_ide_public_endpoint" on data type string

`wp option patch update` then errors with "No data exists for key"
because the array doesn't have the subkey yet, and the fallback `||`
hits the same string-coercion wall.

Just overwrite the whole `graphql_ide_settings` option with the
desired state via `wp option update --format=json`. The other IDE
settings are read through `get_graphql_setting()` which defaults a
non-array section to `[]` and falls back to each field's declared
default, so absence == declared default for any field not in the
payload. `afterAll` resets `graphql_ide_public_endpoint` to "off",
which is also its declared default.

Two changes:

1. Write the assembled Playground URL to `$GITHUB_STEP_SUMMARY` from
   the build workflow. This makes the link reachable on the workflow
   run page for every PR — including fork PRs and including this PR
   itself — without depending on the workflow_run-triggered sticky
   comment landing first. Step summaries don't need any special token
   permissions, which is the whole point.

   Follows the WordPress Playground "Open in Playground" badge
   convention via a shields.io badge → playground.wordpress.net#<blueprint>
   URL, so reviewers see a button that matches the rest of the
   ecosystem (Gutenberg PRs, core Playground demos).

2. Compute the Playground URL once in the build workflow and stash it
   in the pr-meta artifact alongside PR_NUMBER and HEAD_SHA. The
   comment workflow now reads the URL instead of rebuilding the same
   base64 blueprint with the same heredoc. Single source of truth,
   and a blueprint change touches one file.

`wp-scripts plugin-zip` derives the output filename from package.json's
`name` field and adds discovered files flat at the archive root. The
IDE's workspace name `@wpgraphql/wp-graphql-ide` makes that produce:

  - filename `@wpgraphql/wp-graphql-ide.zip` (with `@wpgraphql/` as a
    literal subdirectory of the build cwd)
  - contents flat at root (no top-level wrapping directory)

Both of those are wrong for any consumer that follows the WP plugin
convention. WordPress, wp.org's installer, and WordPress Playground's
`installPlugin` step all expect a ZIP containing a single top-level
directory whose name equals the plugin slug. Without it, Playground's
extraction lands files in a derived location that doesn't match
`wp-content/plugins/wp-graphql-ide`, so the subsequent `activatePlugin`
step fails with "wasn't able to find the plugin
/wordpress/wp-content/plugins/wp-graphql-ide".

Replace `build:zip` with `bin/build-plugin-zip.js`, which reuses the
same file discovery (`npm-packlist`, honoring the `files` field) but
writes everything under a `wp-graphql-ide/` prefix to a flat
`wp-graphql-ide.zip` at the workspace root. `adm-zip` and
`npm-packlist` are already transitively available via
`@wordpress/scripts`, so no new dependencies.

The Playground preview workflow can now skip its "Normalize ZIP
filename" find/mv hack — the build script writes the right artifact
in the right place directly.

Also: add `wp-graphql-ide.zip` (with the dash matching the plugin
slug) to the IDE's .gitignore; the existing entry was for the old
slug-less filename `wpgraphql-ide.zip`.

`actions/upload-artifact@v4` always wraps whatever it's given in a
ZIP — that wrapper is the file the user (or Playground, via
nightly.link) downloads. Uploading our already-built
`wp-graphql-ide.zip` as a single file therefore produced a
double-zipped download: extracting one level revealed the inner ZIP
file at the root, not the plugin directory. Playground's
`installPlugin` step extracts exactly one level, found a `.zip`
sitting where a plugin folder should be, and the subsequent
`activatePlugin` failed with "wasn't able to find the plugin
/wordpress/wp-content/plugins/wp-graphql-ide".

Extract the properly-shaped ZIP into a staging dir and upload the
extracted contents instead. GitHub's artifact wrapper becomes the
one and only ZIP layer, the download contains `wp-graphql-ide/<files>`
at its root, and Playground's installer is happy.

`build:zip` itself still produces `wp-graphql-ide.zip` for wp.org /
manual distribution — only the Playground workflow's artifact path
changes.

…it up

`actions/upload-artifact@v4` defaults `include-hidden-files` to false
and skips paths whose names start with `.`, so the previous staging
dir `.playground-artifact/` produced "No files were found with the
provided path" and uploaded nothing. Drop the dot from both the
workflow path and the .gitignore entry — staging is meant to be
visible to the upload action.

The new bin script written in 7f2b6d9 used spaces inside parens /
braces (the @wordpress/scripts-style I'd written from muscle memory),
which the IDE's Prettier config rejects. 16 auto-fixable formatting
errors, no behavior change. Ran `lint:js:fix` to align with the
rest of the workspace.

The `files` field in `package.json` listed `build`, `styles`,
`plugins/*/*.php`, etc. but omitted `includes` — so every PSR-4
class file and every modular helper that `wpgraphql-ide.php`
require_once's was missing from the published archive. The very
first line of plugin bootstrap is

  require_once __DIR__ . '/includes/access-functions.php';

which fataled with no output, surfacing in WordPress Playground as

  PHP.run() failed with exit code 255
  === Stdout === (empty)
  === Stderr === (empty)

(Empty streams because PHP died before any output buffering ran.)

Add `includes` to the files list. Verified locally: rebuilt ZIP now
contains 19 PHP files from `includes/` (access-functions.php,
Access.php, AdminUI.php, AssetEnqueue.php, SmartCacheBridge.php,
the document-settings/ subtree, etc.) where it previously had zero.

The same gap would have broken wp.org installs the moment users
tried to download the published ZIP. Bug pre-dates this branch — the
files list never had it.

Regression guard for the bug fixed in ad9a664. The IDE's
\`package.json\` \`files\` list and the entry file's \`require_once
__DIR__ . '/...'\` graph have to stay in sync — when they don't, the
published ZIP is missing files the plugin needs at load time and the
install fatals before any output buffer flushes (which is why
Playground saw \`PHP.run() failed with exit code 255\` with empty
stdout AND empty stderr).

The test:
  - Rebuilds wp-graphql-ide.zip via bin/build-plugin-zip.js so the
    assertion is over what would actually ship, not a stale artifact.
  - Asserts the archive has a single \`wp-graphql-ide/\` top-level
    directory (Playground / WP / wp.org all require it).
  - Parses every \`require_once __DIR__ . '/path.php'\` literal out of
    wpgraphql-ide.php and asserts each target is in the archive.
    Adding a new require automatically extends coverage — no test
    edits needed.
  - Filters the one conditional require (\`vendor/autoload.php\`,
    intentionally optional; the SPL fallback covers it).
  - Asserts the four webpack entry points the IDE enqueues at
    runtime (.js + .asset.php for both main and render bundles).

Wired into \`.github/workflows/playground-preview.yml\` as a step
after build so every fork PR runs it — Jest isn't otherwise in CI
yet, and running this single spec adds <1s.

Lives at \`tests/unit/specs/distribution/\` rather than \`.../build/\`
because the plugin's \`.gitignore\` has a top-level \`build/\` entry
(for the webpack output dir) that would otherwise swallow this
file too.