ci: gate the four playgrounds on pull requests

[ifaouibadi]

The four playgrounds were built and type-checked by nothing. pnpm check:types
filters to ./packages/**, no workflow referenced playgrounds/ in any form,
and the unit suites import from source — so the one place the framework bindings
get exercised the way a consumer uses them, through a real bundler against the
public entry points, had no gate at all. That is how four broken playground
builds accumulated undetected.

What this adds

A Playgrounds workflow: install, pnpm build, then pnpm build:playgrounds
over all four, plus a git diff --exit-code guard on the Next playground's
generated files.

pull_request only, filtered to playgrounds/**, packages/**,
pnpm-lock.yaml and the workflow file itself — a playground can only break from
one of those, so a crates/ or bindings/ pull request does not pay for it.
No push trigger: the agent/** push leg in ci.yml already lets a branch gate
itself, and duplicating it here would pay twice per commit while a pull request
is open. No schedule: — nothing reads a nightly result.

One job building four playgrounds sequentially, not a matrix leg each: a matrix
would pay for four checkouts, four installs and four pnpm builds to
parallelise about 12s of actual playground building.

The generated-file problem, and why it is fixed rather than worked around

next build rewrote two tracked files into a state biome ci rejects:

• playgrounds/next/tsconfig.json — Next sets jsx to react-jsx and adds
  .next/dev/types/**/*.ts to include, and rewrites the whole file in its own
  formatting while doing it. Both values are now committed, biome-formatted.
  Next only writes the file when a value is missing, so with them present it
  leaves the formatting alone. Verified: next build twice over, no diff.
• playgrounds/next/next-env.d.ts — Next 16 replaced the /// <reference path>
  line with two import statements, and it writes them with double quotes and
  semicolons. This repo's biome config is single quotes, no semicolons. That one
  is not reconcilable: the file is regenerated on every build and says so in its
  own header. It is committed exactly as Next emits it and dropped from biome's
  file list — one generated file, by exact path, not a directory.

The git diff --exit-code -- playgrounds/next step is what keeps both true. If
it ever fails, run pnpm build:playgrounds locally and commit what Next wrote.

Also

playgrounds/vite-solid built with vite build and no type-check at all,
unlike vite-react's tsc && vite build. It now type-checks. It was already
clean; this closes the hole rather than fixing a break.

pnpm build:playgrounds is a root script so the gate and a developer run the
same command.

Evidence

From a clean tree at this branch's head, Node 22.23.2, pnpm 10.33.0:

pnpm install --frozen-lockfile   1.8s   (warm store; ~20s on a cold runner cache)
pnpm build                      16.0s
pnpm build:playgrounds          12.4s   all four green
git diff --exit-code -- playgrounds/next   clean
pnpm check:ci                   869 files, no fixes applied

The gate was proved to fail, not just to pass:

• A type error injected into playgrounds/vite-solid/src/App.tsx →
  error TS2322, exit 2. Before this branch that file was never type-checked.
• export * from '../actions/compileContract' removed from
  packages/core/src/exports/index.ts → Export compileContract doesn't exist in target module, build failed. A public-surface narrowing in packages/core
  now fails on the playgrounds.

Cost

Zero billable minutes. This repository is public, so GitHub-hosted standard
runners are free on it — GET /actions/runs/{id}/timing reports
billable.UBUNTU.total_ms: 0 for the most recent pull request run. The cost is
wall-clock only: about 1m30s of runner time on the pull requests that touch
packages/ or playgrounds/, against the Build job's current 39s.

[github-actions]

Thanks for the pull request — it is in the queue and a maintainer will review it.

This repository is maintained on a weekly cadence. Anything opened from outside gets
a human reply within 2 business days; this comment is automation confirming your
pull request landed, and it is not that reply.

What happens next:

• CI runs on the pull request. Check, Build and Test need to be green before
  review — you can push fixes straight to the same branch.
• A maintainer reviews it against CONTRIBUTING.md.
• A change to a package's public API, or a new dependency, needs a maintainer
  decision before it can merge. That is where the call gets made rather than a
  delay, and we will tell you either way instead of leaving it open.

If this is a security fix for an unreported vulnerability, please close it and use
the private channel first — SECURITY.md.
A public pull request describes the flaw to everyone before the fix is released.