ci: faz o Dependabot cobrir dependências transitivas do Cargo

[NullSablex]

Mesma mudança que entrou no mysql_samp#43, replicada aqui. Só o .github/dependabot.yml muda.

O problema

Por padrão o Dependabot só acompanha o que está no manifesto, e a maior parte do que o Cargo.lock fixa não vem do Cargo.toml — vem através de outras crates. Uma versão corrigida de uma dessas nunca aparece sozinha: ninguém está olhando para ela. O resultado é que o cargo audit só reporta o problema quando alguém abre um PR qualquer — e reprova esse PR, que não causou nada.

Foi exatamente o que aconteceu no mysql_samp com o RUSTSEC-2026-0285: o rustls corrigido estava publicado havia dias, chegava via mysql, não estava no Cargo.toml, e nada o trouxe até o audit reprovar um PR do Dependabot que só subia versões de actions.

Vale notar que o Dependabot também não teria alertado: o GHSA correspondente não existe no banco de advisories do GitHub (404 na API até hoje). O cargo audit lê o RustSec; o Dependabot lê o GHSA. São bancos diferentes.

A correção

allow: dependency-type: "all", que a referência oficial lista como suportado para cargo:

all — All explicitly defined dependencies. For bundler, pip, composer, cargo, gomod, uv, also the dependencies of direct dependencies.

Com isso a rodada semanal renova também as transitivas: uma versão corrigida chega como bump de lockfile comum e passa pelo cargo audit do CI como qualquer outra mudança. Como o grupo cargo casa *, tudo continua vindo em um PR por semana, não um por crate.

O grupo novo cargo-security existe porque um grupo vale só para version updates a menos que diga o contrário (applies-to: security-updates). Sem ele, vários advisories de uma vez virariam vários PRs.

O que esperar

O primeiro PR do Dependabot depois disto tende a ser maior que o normal — é o primeiro refresh do lockfile inteiro, não só das diretas. Os seguintes voltam ao tamanho de sempre.

Este repositório já roda cargo audit no CI, então a rede de proteção na entrada continua a mesma.