Run the end-to-end suite on pull requests into milestone and wip branches

A release's work is now collected on a milestone branch (milestone/v0.4.0)
before it reaches main, and the suite only ran on pull requests into main,
so nothing proposed for the milestone was tested. `milestone/**` joins
`main`, and `wip/**` comes along from wip/28, where it already runs the
suite on the phases of #28 — the same block on both, so they merge
without a conflict.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

.github/workflows/e2e.yml

@@ -56,8 +56,18 @@ on:
     # Kept, and cheap: a pull request is somebody proposing a change, which is
     # exactly when a second opinion from the suite is worth having, and there
     # are few of them.
+    #
+    # `wip/**` as well: a feature too big for one pull request is built on a
+    # `wip/` branch and reviewed in phases, each phase a pull request into that
+    # branch (issue #28 is the first). Those merges are where the phases meet,
+    # so they get the same second opinion a pull request into main does. A
+    # push to a wip branch still does not — the pull request is the check.
+    #
+    # `milestone/**` too: a release's work is collected on a milestone branch
+    # (`milestone/v0.4.0`) before it reaches main, and a pull request into one
+    # is the same proposal a pull request into main is.
     pull_request:
-        branches: [main]
+        branches: [main, 'wip/**', 'milestone/**']
     workflow_dispatch:
 
 # Six runners per push adds up, so a superseded pull request stops paying for