docs(ci): documenter la portée write:repository requise de NPM_TOKEN

L'attache des installeurs/VSIX à la release Gitea réutilise NPM_TOKEN ; ce
token doit porter write:repository EN PLUS de write:package, sinon l'API
release renvoie 403 (l'étape est best-effort, non bloquante : les artefacts
restent disponibles via upload-artifact).

.gitea/workflows/desktop-release.yml

@@ -50,7 +50,9 @@ jobs:
             packages/desktop/release/*.deb
             packages/desktop/release/latest-linux.yml
       # Best-effort : attache les installeurs (+ latest-linux.yml pour l'auto-update) à la release
-      # Gitea du tag (crée la release si absente). Réutilise NPM_TOKEN (même token Gitea).
+      # Gitea du tag (crée la release si absente). Réutilise NPM_TOKEN (même token Gitea) : ce token
+      # doit porter la portée write:repository en plus de write:package, sinon l'API release renvoie
+      # un 403 (l'attache est ignorée, les installeurs restent disponibles en artefact du run).
       - name: Attach installers to Gitea release
         continue-on-error: true
         env:

.gitea/workflows/vscode-release.yml

@@ -46,9 +46,10 @@ jobs:
           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, droits
+      # Réutilise le secret NPM_TOKEN (même token Gitea que la publication du daemon) : ce token doit
-      # repository suffisants pour l'API release). Sans lui, l'étape est ignorée sans faire échouer
+      # porter write:repository en plus de write:package, sinon l'API release renvoie un 403. Sans
-      # le job (continue-on-error) ; le VSIX reste disponible en artefact.
+      # token, l'étape est ignorée sans faire échouer le job (continue-on-error) ; le VSIX reste
+      # disponible en artefact.
       - name: Attach VSIX to Gitea release
         continue-on-error: true
         env: