fix(website): deploy main, not the tag ref (#837)

* fix(website): deploy main, not the tag ref

Two fixes to the release-triggered deploy observed in run 38835604913:

1. The website environment's custom branch policy does not admit tag
refs, and the release event's ref IS a tag — the deploy can never pass
environment protection. Checkout refs/heads/main instead: the release
commit is main's tip by construction (changesets opens the release PR
from main), so the deployed build is the released content.

2. Restore job-level concurrency (lost when the workflow landed on main
without it): a relay release must fail the job's tag filter before it
enters the deploy queue, not after, or it can replace a queued website
deploy.

* chore(website): add the changeset for the deploy fix

* fix(website): check out the release tag, not main

The environment's branch policy admits nostream-website@* (every
release deploy since 1.1.1 has run on the tag ref), so the
refs/heads/main pin was never needed for admission — and it was wrong
for correctness: main can advance between the release publish and the
job starting, and the pin would build and deploy unreleased content.
Keep the default tag checkout so the deployed build is exactly the
released commit. Also restore the router-worker deploy line the branch
predates.

* docs(website): correct the changeset's checkout description

The changeset still claimed releases deploy main because the
environment rejects tag refs; the fix actually keeps the triggering
tag (which the policy admits) and the real change is the job-scoped
deploy queue. Rewritten before it becomes release notes.

---------

Co-authored-by: Abhay <pandeyabhay967@gmail.com>

Author: chappie-daemon

.changeset/deploy-main-on-release.md

@@ -0,0 +1,5 @@
+---
+"nostream-website": patch
+---
+
+Website deploy workflow fix: the deploy queue is job-scoped so relay releases can't displace a pending website deploy (measured: the nostream@3.5.1 release run was cancelled with zero jobs at the workflow-level concurrency group, before its job-level `if` could skip it). The checkout stays on the triggering `nostream-website@` tag, which the `website` environment's branch policy admits — the deployed build is exactly the released commit.

.github/workflows/deploy-website.yml

@@ -12,12 +12,16 @@ on:
       - published
   workflow_dispatch:
 
-concurrency:
-  group: deploy-website
-  cancel-in-progress: false
-
 jobs:
   deploy:
+    # Concurrency lives on the job, not the workflow: a relay release
+    # (v* tag) fails the if below and must not enter this deploy queue,
+    # where it could replace a queued website deploy. Measured: the
+    # nostream@3.5.1 release run (38845857055) was cancelled with zero
+    # jobs at the workflow-level group, before the job if could skip it.
+    concurrency:
+      group: deploy-website
+      cancel-in-progress: false
     # workflow_dispatch ignores every on: filter — a manual run must not
     # publish a non-main branch to production, so dispatch stays main-only.
     if: >-
@@ -31,6 +35,11 @@ jobs:
     permissions:
       contents: read
     steps:
+      # Checkout gets the release event's default: the tag that triggered the
+      # run (refs/tags/nostream-website@X.Y.Z). The website environment's
+      # branch policy admits nostream-website@* — every release deploy since
+      # 1.1.1 has run on the tag ref — so the build is exactly the released
+      # commit, even if main has advanced by the time the job starts.
       - name: Checkout
         uses: actions/checkout@v3