fix(renovate): point ferrlabs-* cargo deps at the Kellnr sparse index

[BryanFRD]

Closes #184

ferrlabs-* Cargo crates have never received a semver update. Four APIs sit on ferrlabs-errors 0.2.0 while Kit publishes 0.9.1, and that gap is what broke FerrLens (FerrLens-Cloud#262 — ? stopped converting sqlx::Error because the From impl postdates 0.2.0).

Root cause — narrower than the issue described

The issue guessed that both registry discovery and auth were missing. Auth is actually fine: renovate.yml already carries a crates.ferrlabs.com hostRule with hostType: cargo and the Kellnr token.

The real problem is only discovery. These deps declare:

ferrlabs-errors = { version = "0.2.0", registry = "kellnr" }

Renovate resolves the name kellnr through .cargo/config.toml — but that file lives in each repo's api/ subdirectory, which Renovate does not discover. renovate.yml already documents this exact failure in a comment: "where that subdir config isn't discovered (registry index was not found: kellnr)". The env vars it sets fix it for the cargo binary during lockfile maintenance, but Renovate's own datasource lookup is a separate path and still fails — silently, which is why no PR was ever opened.

Fix

Set registryUrls on the ^ferrlabs- cargo packageRule so the lookup bypasses registry-name resolution entirely — the same override the @ferrlabs/ npm rule already uses to point at GHCR.

Also in this PR

vulnerabilityAlerts.prPriority removed. The official renovate-config-validator rejects it: "prPriority can't be used in vulnerabilityAlerts. Allowed objects: packageRules." It was silently ignored, so security-alert PRs never got the priority boost the config intended. Removing it makes the config honest; if the boost is wanted it has to move to a packageRule.

Verification

npx --package renovate renovate-config-validator default.json — the config parses and neither change raises anything.

What this cannot prove locally is that Renovate now finds the crates: that needs a live run against the registry. The check after merge is a ferrlabs-errors 0.2.0 → 0.9.1 PR appearing on one of FerrVault / FerrTrack / FerrGrowth / FerrLens.

Careful on the first wave

The rule carries automerge: true with minimumReleaseAge: 0. A seven-minor jump on a shared error type will not be a clean bump — FerrLens#262 shows it needs code changes. Worth landing this with automerge temporarily off for the cargo rule, or being ready to close the first batch of PRs and stage them per repo.

Separate finding

The validator also flagged packageRules[3].matchMergeConfidence as invalid — that is a different problem with real consequences, filed on its own.

[ferrfleet]

Good root-cause analysis and the prPriority removal is correct (schema does reject it on vulnerabilityAlerts). One blocking issue on the actual fix — see inline comment: the new registryUrls value is missing the sparse+ prefix that this same repo's renovate.yml already uses for the identical Kellnr index URL, so Renovate will likely still fail to resolve ferrlabs-* crates, just via a different code path than the one described in the PR.

[ferrfleet]

Follow-up: the blocking issue from my previous review (missing sparse+ scheme prefix on registryUrls) is fixed in 8d7fd35 — replied on that thread. No new issues in the delta.