fix(renovate): declare the cargo credential provider for the private registry

[BryanFRD]

Suite de #164. Le registre est désormais résolu (Updating 'kellnr' index dans les logs, plus aucun registry index was not found), mais cargo update échoue maintenant plus loin, sur une erreur distincte :

Caused by:
  unable to update registry `kellnr`
Caused by:
  authenticated registries require a credential-provider to be configured

Cause

api/.cargo/config.toml des repos consommateurs contient deux morceaux :

[registries.kellnr]
index = "sparse+https://crates.ferrlabs.com/api/v1/crates/"   # ← répliqué par #164

[registry]
global-credential-providers = ["cargo:token"]                  # ← jamais répliqué

Renovate invoque cargo depuis la racine du repo, où ce fichier n'est pas découvert : cargo cherche .cargo/config.toml en remontant depuis le cwd, pas depuis --manifest-path. Les deux moitiés doivent donc être répliquées ; #164 n'en a répliqué qu'une.

Le piège est que global-credential-providers ne fait que redire le défaut de cargo — mais s'appuyer sur le défaut n'équivaut pas à le déclarer (src/cargo/util/auth/mod.rs) :

let mut global_provider_defined = true;
let default_providers = || {
    global_provider_defined = false;          // ← s'appuyer sur le défaut met ce flag à false
    vec![vec!["cargo:token".to_string()]]
};
let global_providers = gctx
    .get::<Option<Vec<Value<String>>>>("registry.global-credential-providers")?
    .filter(|p| !p.is_empty())
    .map(...)
    .unwrap_or_else(default_providers);
...
if !global_provider_defined && require_cred_provider_config {
    bail!("authenticated registries require a credential-provider to be configured...")
}

Pour un registre auth-required, cargo exige que le provider soit déclaré explicitement, et échoue sinon — même avec un token parfaitement valide. C'est un garde-fou délibéré, pas un bug.

Correctif

Ajout de CARGO_REGISTRY_GLOBAL_CREDENTIAL_PROVIDERS: "cargo:token" à customEnvVariables.

Vérifié dans le code plutôt que dans la doc (qui ne précise pas le format des tableaux via env) : get_env_list dans src/cargo/util/context/mod.rs fait env_val.split_whitespace(), donc "cargo:token" donne bien ["cargo:token"]. Le mapping clé → variable (registry.global-credential-providers → CARGO_REGISTRY_GLOBAL_CREDENTIAL_PROVIDERS) suit la règle documentée : majuscules, points et tirets en underscores.

Validé en local : YAML parsé, JSON valide après interpolation du secret, valeurs identiques à api/.cargo/config.toml.

À confirmer après merge

Aucun check CI ne couvre ceci. Critère de succès sur un run réel : plus aucune artifactErrors cargo. Si le token lui-même pose problème, l'erreur suivante sera un 401/403 — l'auth n'ayant encore jamais abouti jusqu'ici.