[Add] Work on a Gutenberg issue and open a pull request to it (#251)

[juanmaguitar]

Why

The last piece of #251. A Gutenberg site can now clone, build, serve (#255, #261) and have a
Gutenberg pull request applied to it (#264) — but a contributor still could not work on a
Gutenberg issue and open a pull request for it. Linking a work item and authoring a PR were both
Trac- and wordpress-develop-shaped.

Stacked on #264. The final PR of the Gutenberg feature, which merges atomically — see #255.
Do not merge alone.

What changes

• src/renderer/github-issue.cjs (new) — the Gutenberg counterpart of trac-ticket.cjs.
  Accepts 1234, #1234 and an issue URL with the noise a copy-paste brings; refuses another
  repository's issue, another host, and — by name, because it is the obvious mistake — a pull
  request URL pasted instead of the issue it fixes.
• src/work-item.cjs (new) — one interface over the two kinds, chosen by the site's project
  type. The rest of the app asks "parse this", "where does it live", "what is it called" without
  knowing which it is. Defaults to Trac, so a site with no project type is untouched.
• sites:set-ticket validates through the site's provider. Both kinds parse to a number, so the
  ticket/<id> branch key and every reader of tracTicket are unchanged — no migration.
• github-pr.cjs takes the project's upstream, base branch and branch prefix through the deps
  each helper already receives; buildPullRequestBody takes the project's citation line. A
  Gutenberg PR goes to WordPress/gutenberg, on a fix/issue-<n> branch, saying
  Fixes #<n> so merging it closes the issue.
• The handoff patch header cites the same work item instead of deriving a Trac URL from the
  number.
• UI follows the project: the work-item card, its input and the browse link. Both Trac-only
  surfaces are hidden on a Gutenberg site — the attachments panel, and the "Attach to Trac"
  destination.

testMode() deliberately still reads the environment override rather than the project, so a
Gutenberg site is not reported as sandboxed merely for not being wordpress-develop.

How to test this

Platforms: any. Needs a Gutenberg site from the earlier PRs, and a signed-in GitHub account for
step 4.

1. On a Gutenberg site, the work-item card says GitHub issue. Paste
   https://github.com/WordPress/gutenberg/issues/71234 (or #71234). → Linked; "Open on GitHub"
   goes to the issue. A core.trac.wordpress.org URL is refused here, and a pull request URL is
   refused with "That is a pull request. Link the issue it fixes instead."
2. The Trac attachments panel and the Attach to Trac destination are not shown.
3. Make an edit, then Save patch for handoff. → The header says
   # Issue: https://github.com/WordPress/gutenberg/issues/71234, not a Trac URL.
4. Open a pull request. → It targets WordPress/gutenberg, the branch is fix/issue-71234, the
   title defaults to Issue #71234, and the body's first line is Fixes #71234.
5. On a Core site, everything is as before: "Trac ticket" card, 62281 links, attachments panel
   present, handoff header says # Ticket: …/ticket/62281, PR targets wordpress-develop on
   trac-62281 citing the Trac URL.

What must not have happened:

• A Gutenberg pull request must never reach wordpress-develop — that is a real PR on the wrong
  project. test/github-pr.test.cjs drives the whole sequence (fork → ref → sync → tree → commit →
  branch → PR) against a fake API and asserts no call touches wordpress-develop, and the mirror
  test asserts a project-less run touches no gutenberg.
• A Gutenberg site must not be offered a Core patch, or a button that saves a file and then does
  nothing.
• WP_DEV_ENV_GITHUB_UPSTREAM must still redirect a run to a sandbox (it is checked before the
  project, on purpose).

Automated: npm run lint clean; 844 tests pass. New: test/github-issue.test.cjs,
test/work-item.test.cjs; extended github-pr, patch-provenance, ipc-wiring.

Risks and limitations

• Some Core framing remains in copy this PR did not touch (e.g. "Edited files in src/?", the
  stale-trunk note's "may not apply on Trac"). Cosmetic on a Gutenberg site; a copy pass is a
  follow-up.
• workItemProvider('github-issue') with no repoPath would build a github.com/undefined/...
  URL. Not reachable — both call sites pass the site's upstream — but the two halves of that object
  disagree about their contract, worth tightening later.

Related

Part of #251 — completes it. Stacked on #264.

---

Review outcome (required — see AGENTS.md)

5 [fix here] · 1 [follow-up] — all 5 fixed. Ran the review in
.github/instructions/code-review.instructions.md; judgement pass in a fresh subagent. Lint clean,
844 tests pass.

• 🟡 Architecture · fixed — the "Attach to Trac" destination was the one Trac surface left
  ungated; on a Gutenberg site its button saved a patch and then silently did nothing
  (attachUrlFor is null). Now hidden, like the attachments panel.
• 🟡 Security · fixed — parseIssueRef's URL branch skipped the bounds check its bare-number
  branch applied, so /issues/0 produced a falsy id (a site on ticket/0 that reads as unlinked
  and cannot open a PR) and a 20-digit path produced a float-named branch. Both branches now share
  one guard; regression tests added.
• 🟡 Architecture · fixed — the handoff patch header derived a Trac URL from the number, so a
  Gutenberg patch cited a core.trac ticket sharing its issue number. It now takes the work item from
  the caller.
• 🟡 Tests · fixed — nothing pinned that a Gutenberg run targets the right repo through the whole
  flow (only the pure helpers were tested). Added an end-to-end openPullRequest test per project
  asserting no call reaches the other one, plus a Gutenberg github:open-pr wiring test.
• 🔵 Architecture · fixed — the per-project no-ticket message was unreachable behind the
  renderer's message map; dropped the duplicate so the main-process one (which knows the project)
  is what the user sees.
• 🔵 Architecture · [follow-up] — urlFor without a repoPath (documented in Risks; unreachable).
• Verified clean: Core byte-identity of upstream()/baseBranchFor()/branchNameFor()/
  buildPullRequestBody() with no project; the env override still wins over a project;
  testMode() ignoring the project is correct; the attachments gating leaves no orphaned effect or
  loader that could open a Trac window on a Gutenberg site; parseIssueRef rejects
  https://github.com@evil.com/… and builds its URL from the configured repo, not the input.

[juanmaguitar]

Closing along with the rest of the stack — see #255 for the reasoning: trunk has rewritten src/main.js and src/renderer/index.jsx out from under this branch since 907cb65, so rebasing would be a semantic rebase, not a textual one.

The branch stays, so the work is retrievable. What ports forward cleanly here: src/work-item.cjs, src/renderer/github-issue.cjs and their tests.