[Add] a per-site project type driving clone, status and build (#251)

[juanmaguitar]

Why

The toolkit assumes every site is a wordpress-develop checkout — the repo it clones, how it
decides a site is "built", and the run/build commands are all hard-wired to WordPress Core. A
contributor who wants to work on the block editor (Gutenberg) has no path in, even though the shape
of the work is nearly identical. Part of #251.

What changes

Each site gets a project type, chosen once at creation, and that single choice drives the parts
of the flow that differ. This PR covers setup/clone, built-status, and run/build; serving
Gutenberg in a real WordPress (PR next) and the GitHub-issue work-item / pull-request flow (PR after)
follow.

• src/project-type.cjs — one registry describing each target (Core, Gutenberg): clone
  URL/branch, PR upstream, built-check marker path, dev/build scripts, allowed terminal scripts —
  plus the serve strategy, patch layout and work-item provider the later PRs will read.
  getProjectType / projectTypeForSite default to Core for any unknown or missing id, so sites
  created before this field existed need no migration and the Core path stays byte-identical.
• wordpress:setup resolves the type once and uses it for both the clone and the siteMeta it
  writes, so the two cannot disagree; site:status returns it.
• Built-check is per project: Core's build/wp-includes/js/dist vs Gutenberg's
  build/block-library.
• git:update-trunk pulls from the site's own upstream — updating a Gutenberg checkout from
  Core's trunk would overwrite it with a different project.
• Wizard + terminal: a "Contribute to" choice (default Core); the dev-server plan (npm run dev
  vs Core's grunt -- _watch) and the terminal allow-list come from the chosen type. The sidebar
  button, modal and docs are retitled to the type-neutral "contributor site"; the create-site and
  empty-state screenshots are regenerated.

Deliberately not here: no Gutenberg serve yet (a Gutenberg site can clone/install/build but its
Playground preview comes in the next PR), and the work item is still Trac-only (GitHub issues land
with the PR flow).

How to test this

Platforms: any — no path/spawn/line-ending behavior changes; the marker path is composed with
path.join.

Starting state: the app open on the site list.

1. Click Create a contributor site. → Modal titled "Create a contributor site" with a
   Contribute to choice, WordPress Core (Trac tickets) selected.
2. Create a site as Core (don't touch the choice). → Clones wordpress-develop; install, build, and
   dev server behave exactly as before.
3. Create a second site, pick Gutenberg (GitHub issues). → Clones WordPress/gutenberg; after
   npm run build the checklist reports it built (marker build/block-library); the terminal's
   npm run <script> list is Gutenberg's; starting the dev server runs npm run dev (not Grunt).
4. On the Gutenberg site, Update to latest trunk. → Pulls from WordPress/gutenberg, not
   wordpress-develop.

What must not have happened:

• No existing site changed behavior. A site with no projectType reads as Core everywhere, with
  no store rewrite on status read.
• A Gutenberg site must not be reported "built" merely because a build/wp-includes/js/dist
  exists — the marker is its own (test/ipc-wiring.test.cjs pins this negative case).
• The Core clone/build/watch path is byte-identical — same clone args, same grunt -- _watch.

Automated: npm run lint clean; npm test — 797 pass, 0 fail. New/extended coverage in
test/project-type.test.cjs, test/dev-server-command.test.cjs (Gutenberg npm run dev branch),
and test/ipc-wiring.test.cjs (clone URL, built marker incl. the negative, and update-trunk URL per
type; setup persistence + normalization).

Risks and limitations

⚠️ Do not merge this before the rest of the Gutenberg stack. The wizard exposes a live
Gutenberg choice, but only clone/status/build honor the type here — serving Gutenberg in
Playground and the GitHub-issue patch/PR flow land in the following PRs. This PR and its
follow-ups (serve; work-item + PR) are meant to merge together, so the choice never reaches a
user in a half-working state. Merged alone, a contributor who picks Gutenberg would get a site
that clones and builds but cannot be previewed or produce a valid patch/PR. Review outcome below.

• Some UI/docs copy still uses Core's src/ framing (e.g. "Edited files in src/? Run npm run
  build"); a Gutenberg-aware copy pass rides with the later, user-facing PRs.

Related

Part of #251.

---

Design decisions and alternatives considered

• One registry, not scattered if (type === …). The Core assumptions were spread across clone,
  status, dev-server-command.cjs, and the trunk-update URL. Consolidating them into
  src/project-type.cjs turns each hard-wired constant into a lookup whose Core value reproduces
  today's behavior, so the Core diffs read as pure refactors.
• Default-to-Core on read, so no migration. Existing siteMeta records simply lack the field;
  projectTypeForSite(undefined) yields Core. Nothing is rewritten on disk.
• Folded the "honor the type" work into the same PR as the picker. An earlier plan split this
  into an inert spine + a follow-up; combining them means the wizard never exposes a choice the app
  ignores, which removed a self-review finding entirely. Still under the size guideline (~490 lines).
• git:update-trunk had to become type-aware here, not later — a Gutenberg site updating from
  Core's trunk is a data-loss bug, so it could not wait for a serve/PR PR.

Review outcome (required — see AGENTS.md)

1 [fix here] · 0 [follow-up]. Ran the review in
.github/instructions/code-review.instructions.md against the branch; judgement pass dispatched to
a fresh subagent. npm run lint clean, 797 tests pass.

• 🟡 Architecture · [fix here] — the wizard exposes a live Gutenberg option while three registry
  facts (serve.strategy, patch.layout, pr.*/workItem) are not yet consumed, so a Gutenberg
  site can clone/build but not be served or produce a valid patch/PR. Resolved by merge strategy,
  not by code: this PR and the serve + work-item/PR follow-ups merge together (see the banner in
  Risks), so the option never reaches a user in the broken state. Deliberately kept the choice live
  rather than gating it, because the stack lands atomically.
• No findings on the default-to-core seam across the new consumers, electron-store migration,
  site:status marker/meta ordering, renderer memoization stability, IPC validation, cross-platform
  path composition, or test quality (the per-type tests, including the negative built-marker case,
  go red if a consumer stops honoring the type).

Screenshots or recording

The create-site modal now offers a Contribute to choice (WordPress Core / Gutenberg), Core
preselected, and the sidebar button + modal are retitled. Regenerated docs screenshots:
docs/public/screenshots/create-site-modal.png and empty-state.png.

[juanmaguitar]

Heads-up on the extra commit here: 53ea586 cherry-picks #390 (a0fcbc9) onto this branch, and the four PRs stacked on top of it (#261, #264, #269, #283) picked it up by merging down the stack.

Buildkite is archived right now so that no signing build runs pre-#390 code and writes the rotated App Store Connect key back into the package. Getting the fix onto every open branch is what lets the pipeline be un-archived, so it went in as a cherry-pick rather than waiting for this stack to catch up with trunk — that catch-up is still owed (50 commits, including the test/ → tests/ move in #377) and is unrelated to the incident.

Two pieces of #390 were left out because this branch predates the infrastructure they hook into: the packaged smoke canary (tests/e2e/packaged/smoke.spec.js) and its e2e.yml step. The unit test came along and keeps its tests/unit/ path, which is what it resolves the signing script from; it passes here.

[juanmaguitar]

Closing this stack rather than rebasing it.

The branch point is 907cb65. Since then trunk has rewritten the two files every PR in this stack wires into: src/renderer/index.jsx gained ~755 lines across 20 commits, src/main.js ~356. This PR also edits the patch layer that #318, #302 and #291 restructured. Resolving those conflicts is a semantic rebase, not a textual one — the markers would clear and the result would be quietly wrong.

The branch is not deleted, so nothing here is lost. What ports forward intact when this is redone is the new modules and their tests, none of which conflict with anything: src/project-type.cjs and test/project-type.test.cjs. The wiring into main.js and index.jsx has to be written against todays code either way.

#283 stays open — it only needs its own node-shims.cjs, so it has been rebased onto trunk as a standalone PR.