fix(ci): derive IMAGE from github.repository, not the schedule-empty event payload

`${{ github.event.repository.name }}` resolves to EMPTY on `schedule`
events since the Gitea upgrade (now 1.27.0), so IMAGE would resolve to
"justin/" and the image build would fail with

  ERROR: failed to build: invalid tag
  "192.168.0.2:1234/justin/:latest": invalid reference format

This is confirmed in seed-mcp and opsramp-docs, which share this
workflow's lineage. Here the bug is still latent: the monthly refresh
has been failing earlier, during the epa_ppls scrape, when the job
container disappears (`docker daemon ping ... context deadline
exceeded`) roughly 3 h in — a separate runner-side problem that this
commit does NOT address.

- IMAGE now comes from `${{ github.repository }}` (run context, not the
  event payload — `github.repository_owner` from the same source was
  resolving fine all along).
- The package-link and registry-GC steps take the bare repo name from
  `${GITHUB_REPOSITORY##*/}` (POSIX, safe under dash).
- New `Verify image name resolves` step fails in seconds instead of
  after a full scrape if this ever regresses.

Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01FnVuG79cYPcRLTp4pC8ujR

.gitea/workflows/image-only.yml

@@ -30,7 +30,7 @@ concurrency:
 env:
   REGISTRY_PUSH: 192.168.0.2:1234
   REGISTRY_PULL: git.jpaul.io
-  IMAGE: ${{ github.repository_owner }}/${{ github.event.repository.name }}
+  IMAGE: ${{ github.repository }}
   OLLAMA_URL: http://192.168.0.2:11434,http://192.168.0.2:11435,http://192.168.0.125:11434
   EMBED_MODEL: nomic-embed-text
   PRODUCT_NAME: crop_chem
@@ -46,6 +46,19 @@ jobs:
         with:
           fetch-depth: 0
 
+      - name: Verify image name resolves
+        # ${{ github.event.repository.name }} silently resolves to EMPTY on
+        # schedule events (Gitea >=1.27), which built the tag
+        # "192.168.0.2:1234/<owner>/:latest" and failed the build only AFTER
+        # the full scrape. IMAGE now comes from github.repository; this step
+        # fails in seconds if it ever goes empty again.
+        run: |
+          echo "IMAGE=${IMAGE}"
+          case "${IMAGE}" in
+            */?*) ;;
+            *) echo "ERROR: IMAGE did not resolve to owner/repo"; exit 1 ;;
+          esac
+
       - name: Set up Python
         uses: actions/setup-python@v5
         with:
@@ -88,7 +101,7 @@ jobs:
           GITEA_TOKEN: ${{ secrets.REGISTRY_TOKEN }}
         run: |
           OWNER="${{ github.repository_owner }}"
-          PKG="${{ github.event.repository.name }}"
+          PKG="${GITHUB_REPOSITORY##*/}"
           BODY=$(mktemp)
           CODE=$(curl -sS -o "$BODY" -w "%{http_code}" -X POST \
             -H "Authorization: token ${GITEA_TOKEN}" \
@@ -112,6 +125,6 @@ jobs:
         run: |
           python scripts/registry_gc.py \
             --owner "${{ github.repository_owner }}" \
-            --package "${{ github.event.repository.name }}" \
+            --package "${GITHUB_REPOSITORY##*/}" \
             --keep-days 180 \
             --keep-latest 6

.gitea/workflows/refresh.yml

@@ -29,7 +29,7 @@ env:
   # Self-hosted Gitea registry on the same LAN as the runner.
   REGISTRY_PUSH: 192.168.0.2:1234
   REGISTRY_PULL: git.jpaul.io
-  IMAGE: ${{ github.repository_owner }}/${{ github.event.repository.name }}
+  IMAGE: ${{ github.repository }}
 
   # Embedder pool for the reindex step. Two Ollama instances on the
   # Gitea/runner host (one per GPU) + the Windows Ollama. Trashpanda's
@@ -50,6 +50,19 @@ jobs:
         with:
           fetch-depth: 0
 
+      - name: Verify image name resolves
+        # ${{ github.event.repository.name }} silently resolves to EMPTY on
+        # schedule events (Gitea >=1.27), which built the tag
+        # "192.168.0.2:1234/<owner>/:latest" and failed the build only AFTER
+        # the full scrape. IMAGE now comes from github.repository; this step
+        # fails in seconds if it ever goes empty again.
+        run: |
+          echo "IMAGE=${IMAGE}"
+          case "${IMAGE}" in
+            */?*) ;;
+            *) echo "ERROR: IMAGE did not resolve to owner/repo"; exit 1 ;;
+          esac
+
       - name: Set up Python
         uses: actions/setup-python@v5
         with:
@@ -135,7 +148,7 @@ jobs:
           GITEA_TOKEN: ${{ secrets.REGISTRY_TOKEN }}
         run: |
           OWNER="${{ github.repository_owner }}"
-          PKG="${{ github.event.repository.name }}"
+          PKG="${GITHUB_REPOSITORY##*/}"
           BODY=$(mktemp)
           CODE=$(curl -sS -o "$BODY" -w "%{http_code}" -X POST \
             -H "Authorization: token ${GITEA_TOKEN}" \
@@ -158,6 +171,6 @@ jobs:
         run: |
           python scripts/registry_gc.py \
             --owner "${{ github.repository_owner }}" \
-            --package "${{ github.event.repository.name }}" \
+            --package "${GITHUB_REPOSITORY##*/}" \
             --keep-days 180 \
             --keep-latest 6

CLAUDE.md

@@ -146,8 +146,12 @@ identifiers that the LLM reads.
 
 You do NOT need to edit the IMAGE env or the `--package` arg in the
 workflows. Both derive from the repo at runtime via
-`${{ github.repository_owner }}` and
-`${{ github.event.repository.name }}`. So a clone into a repo named
+`${{ github.repository }}` and `${GITHUB_REPOSITORY##*/}`. Do **not**
+use `${{ github.event.repository.name }}` — it resolves to EMPTY on
+`schedule` events (Gitea >= 1.27), which silently builds the tag
+`<registry>/<owner>/:latest` and fails the build *after* the full
+scrape; the `Verify image name resolves` step guards it. So a clone
+into a repo named
 `my-product-docs` automatically pushes the container as
 `<owner>/my-product-docs:latest` and links the package to its own
 repo. (`github.*` is Gitea Actions' inherited GitHub-Actions