ci: a runner label names the platform, not the org

hanzo-build-linux-amd64, lux-build-linux-amd64, zoo-build-linux-amd64 and
every other org-prefixed spelling all meant the same machine. Which org a
job belongs to does not change which host can build it, so the org bought
one pool name per org per arch and each could go stale on its own -- the
evo host alone answered to fourteen names for one label.

One vocabulary now: linux-amd64, linux-arm64, macos-arm64, win-amd64. The
generic labels every plain workflow uses (ubuntu-latest, self-hosted) are
untouched, so naive CI keeps working.

Co-authored-by: Hanzo Dev <[email protected]>

.hanzo/workflows/docs.yml

@@ -32,7 +32,7 @@ concurrency:
 
 jobs:
   build:
-    runs-on: [lux-build-linux-amd64]
+    runs-on: [linux-amd64]
     timeout-minutes: 20
     steps:
       - uses: actions/checkout@v4

.hanzo/workflows/release.yml

@@ -6,7 +6,7 @@ name: Release
 # work here:
 #
 #   * `runs-on: [self-hosted, linux, amd64]` is the bare triple. The pool on
-#     this forge is named `lux-build-linux-amd64`; nothing answers to the
+#     this forge is named `linux-amd64`; nothing answers to the
 #     triple, and a job naming a label no runner carries does not fail, it
 #     waits.
 #
@@ -42,7 +42,7 @@ concurrency:
 
 jobs:
   docker:
-    runs-on: [lux-build-linux-amd64]
+    runs-on: [linux-amd64]
     # The arm64 leg compiles under emulation; 45 minutes was sized for amd64
     # alone and would abort the release part-way through the second platform.
     timeout-minutes: 180