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>
c7dc8f707a