ci: peel the gtk3 multi-window e2e gate into its own job

[rigel-mintaka]

This PR is part of a stack containing 3 PRs:

1. main
2. ci: peel the forge live-contract oracle into its own peer job (RIG-2698 T3) #610
3. "ci: peel the gtk3 multi-window e2e gate into its own job" (this PR)
4. ci: moon concern matrix; dissolve gates; gate every leg (RIG-2700 T5) #621

Per docs/designs/infra/ci/compass-ci-job-decomposition/design.md § Plan → T4:
lift the Multi-window gtk3 e2e gate step out of the monolithic gates job
into a dedicated gtk3-e2e peer job behind the single required CI rollup.
Fourth of the five-task decomposition (after pgtest, microvm, forge-oracle);
gates now holds only the checkout, the two-phase bootstrap, the parity check,
the two moon steps, and Retrospect.

The gate step is MOVED byte-for-byte — its if: success(), working-directory: go, env: CGO_ENABLED: '1', and the entire run block (the affected git -C ..
diff guard, the out-of-band nix build of the WebKitGTK/xvfb closure from
tools/toolchain/gtk-e2e-env.nix, the xvfb-run invocation, and the PASS-line
guard) are unchanged. Only its parent job changed.

The new job runs on bare ubuntu-latest (no privileged container), under the
shared workflow_dispatch/no-op-edited guard, timeout-minutes: 30,
TMPDIR: /tmp. Its scaffold matches the forge-oracle peer:

• checkout@v7.0.1 with fetch-depth: 0 — the gate's affected diff runs
  git -C .. diff against the base branch, so it needs base-branch history.
• install-nix-action@v31 with the in-repo substituter/key pin (not
  accept-flake-config), byte-identical to the sibling jobs.
• The phase-one "Put the language toolchains on PATH" bootstrap — the gate runs
  go test, and gtk-e2e-env.nix provides only xvfb-run/pkg-config/cc,
  not go, so the phase-one go is required. Phase two is deliberately NOT
  copied: the gate realizes its own WebKitGTK/xvfb closure out of band, so it
  needs none of the phase-two nixpkgs tools.

The job runs unconditionally; its in-step affected guard is retained as
defense-in-depth. Hoisting affected detection into a setup job and adding a
job-level gtk3_affected gate is T5's scope.

The CI rollup gains gtk3-e2e in needs and in the success assertion (a
gtk3 local shell var for the hyphenated job context, matching the
forge-oracle/dogfood-e2e precedent), the echo, the != success gate, and the
::error:: message.

No moon.yml change: unlike the microvm peel, the frozen design scopes no
closure-honesty input to this task.

Refs RIG-2699

Co-authored-by: Matt Wilkinson matt@rigel.build

[linear-code]

RIG-2699

[github-actions]

Compass engineering docs preview: https://compass-runner-2699-ci-gtk3.compass-eng-docs.pages.dev

Deployed from compass-runner/2699-ci-gtk3-e2e-peer-job at 164c02d.