fix(renovate): pass private cargo registry env vars through to the Renovate container

[BryanFRD]

Problème

Les mises à jour de lockfile cargo échouent en renovate/artifacts, sans target_url sur le status — l'erreur réelle n'est visible que dans le log du run :

Command failed: cargo update --config net.git-fetch-with-cli=true --manifest-path api/Cargo.toml ...
error: failed to parse manifest at `api/Cargo.toml`
Caused by:
  registry index was not found in any configuration: `kellnr`

Ça casse au parsing du manifeste, avant tout accès réseau — ce n'est donc pas un problème de credentials sur le registre privé (aucun 401/403).

Cause

renovatebot/github-action filtre process.env par une regex avant de peupler le conteneur Docker Renovate. Dans src/input.ts, au digest épinglé ici (b50d2ba, v46.1.18) :

envRegex: /^(?:RENOVATE_\w+|LOG_LEVEL|GITHUB_COM_TOKEN|NODE_OPTIONS|NO_COLOR|(?:HTTPS?|NO)_PROXY|(?:https?|no)_proxy)$/
...
Object.entries(process.env).filter(([key]) => envRegex.test(key))

CARGO_REGISTRIES_KELLNR_* ne matche pas → les variables n'entrent jamais dans le conteneur, et cargo ignore l'existence du registre. Elles apparaissent malgré tout dans le log parce que GitHub Actions affiche le bloc env: du step : présentes côté runner, absentes côté conteneur, d'où un échec trompeur.

RENOVATE_HOST_RULES passe (préfixe RENOVATE_), ce qui explique que la découverte des versions fonctionne et que les PR s'ouvrent normalement — seule la régénération du lockfile casse.

Correctif

env-regex = le défaut de l'action + CARGO_REGISTRIES_KELLNR_(?:INDEX|TOKEN).

Aucun check CI ne valide cette regex : elle a donc été vérifiée en local en rejouant le chemin exact de l'action (YAML parsé → new RegExp → .test(key)).

• Les deux variables du registre passent.
• Tout ce que le défaut autorisait passe encore (LOG_LEVEL, NODE_OPTIONS, proxies, RENOVATE_*) — aucune régression.
• Rien de nouveau ne fuite (AWS_SECRET_ACCESS_KEY, GITHUB_TOKEN, PATH restent bloqués).

Vérification restante

Résoudre le registre va exercer l'auth pour la première fois. Si le token est mal câblé, une seconde erreur apparaîtra — distincte et reconnaissable : un 401/403, et non plus un registry index was not found. À confirmer au prochain run planifié.