ci(v1): pin workflow branch filters to v1/main

The push filter still listed `main`, and `pull_request` carried no branch
filter at all — both leftovers from when the v1 line was itself `main`.
Neither describes the topology now: `v1/main` publishes straight to the
`v1-latest` dist-tag and never merges into `main`, which carries v2 and
publishes `latest`.

No behavior change on any path that runs today. For `push`, GitHub runs the
workflow file from the pushed commit, so this file was only ever consulted
for `v1/main`; `main` could not match unless a commit on that branch carried
a v1-shaped tree. The same resolution rule made the unfiltered
`pull_request` harmless, since a PR's workflow comes from its merge ref.
The `release` trigger is untouched, so publishing is unaffected — it is
gated on the event type and the release's target commit, never on these
filters.

The value is that the file now states its intent, and the stale `main`
entry can no longer become live if anything is ever restored onto that
branch.

Closes #2065

Signed-off-by: cliffhall <cliff@futurescale.com>

.github/workflows/main.yml

@@ -1,9 +1,18 @@
+# `v1/main` is the deprecated maintenance line: it publishes straight from this
+# branch to the `v1-latest` dist-tag and never merges into `main`, which now
+# carries v2. Keep these filters pinned to `v1/main` — a stale `main` entry here
+# describes a topology that no longer exists, and would start matching the moment
+# anything put a v1-shaped tree back on that branch.
+#
+# (For `push`, GitHub runs the workflow file from the pushed commit, so this file
+# is only ever consulted for `v1/main` regardless. The filter states intent.)
 on:
   push:
     branches:
-      - main
       - v1/main
   pull_request:
+    branches:
+      - v1/main
   release:
     types: [published]