ci: un token de release refusé doit faire échouer le job, pas passer inaperçu

Avec un NPM_TOKEN expiré, les trois workflows de release sont ressortis « réussis » alors qu'aucune
release n'avait été créée et qu'aucun asset n'était attaché : l'attache était en continue-on-error et
le script sortait en 0 quand l'API refusait le token. Diagnostiquer a demandé de comparer les assets
de releases pour comprendre ce que les logs auraient dit tout de suite.

Désormais : token ABSENT (fork, run sans secret) reste un cas légitime qui sort proprement, mais un
token PRÉSENT et refusé, ou un upload d'asset en échec, fait échouer le job avec un message qui nomme
les portées attendues. Les artefacts du run sont uploadés AVANT cette étape, donc un job rouge ne
perd aucun binaire.

L'attache du VSIX passe au même script partagé : elle dupliquait la logique, avec le même angle mort.

.gitea/workflows/vscode-release.yml

@@ -45,31 +45,15 @@ jobs:
         with:
           name: vsix
           path: packages/vscode/*.vsix
-      # Best-effort : attache le VSIX à la release Gitea du tag (crée la release si absente).
-      # Réutilise le secret NPM_TOKEN (même token Gitea que la publication du daemon) : ce token doit
-      # porter write:repository en plus de write:package, sinon l'API release renvoie un 403. Sans
-      # token, l'étape est ignorée sans faire échouer le job (continue-on-error) ; le VSIX reste
-      # disponible en artefact.
+      # Attache le VSIX à la release Gitea du tag (créée si absente), via le script partagé avec la
+      # release desktop : la logique était dupliquée, avec le même angle mort. Réutilise le secret
+      # NPM_TOKEN (même token Gitea que la publication du daemon), qui doit porter write:repository en
+      # plus de write:package. Sans token du tout, le script sort proprement ; avec un token REFUSÉ, il
+      # échoue, pour que l'anomalie soit visible (le VSIX reste dans les artefacts du run).
       - name: Attach VSIX to Gitea release
-        continue-on-error: true
         env:
           RELEASE_TOKEN: ${{ secrets.NPM_TOKEN }}
         run: |
-          if [ -z "$RELEASE_TOKEN" ]; then
-            echo "::notice::NPM_TOKEN absent : VSIX disponible en artefact uniquement."
-            exit 0
-          fi
-          api="${GITHUB_SERVER_URL}/api/v1/repos/${GITHUB_REPOSITORY}"
-          auth="Authorization: token ${RELEASE_TOKEN}"
           version=$(node -p "require('./packages/vscode/package.json').version")
-          vsix="packages/vscode/git-arboretum-${version}.vsix"
-          # id de release du tag, sinon création
-          rid=$(curl -fsSL -H "$auth" "${api}/releases/tags/${GITHUB_REF_NAME}" | node -p "JSON.parse(require('fs').readFileSync(0,'utf8')).id || ''" || true)
-          if [ -z "$rid" ]; then
-            rid=$(curl -fsSL -X POST -H "$auth" -H 'Content-Type: application/json' \
-              -d "{\"tag_name\":\"${GITHUB_REF_NAME}\",\"name\":\"Arboretum VSCode ${version}\"}" \
-              "${api}/releases" | node -p "JSON.parse(require('fs').readFileSync(0,'utf8')).id || ''")
-          fi
-          curl -fsSL -X POST -H "$auth" -F "attachment=@${vsix}" \
-            "${api}/releases/${rid}/assets?name=git-arboretum-${version}.vsix"
-          echo "VSIX attaché à la release ${GITHUB_REF_NAME}."
+          bash .gitea/scripts/attach-release-assets.sh "${GITHUB_REF_NAME}" "Arboretum VSCode ${version}" \
+            "packages/vscode/git-arboretum-${version}.vsix"