fix(publishers): report the crate name from Cargo.toml, not the ferrflow name

[BryanFRD]

Closes #948. Symmetric to #961, which fixed the same defect in the npm publisher.

The cargo publisher built its success URL from the FerrFlow package name rather than the crate name. published_name now reads [package].name from the package's Cargo.toml, falling back to the FerrFlow name when the manifest cannot be read.

The upload was never wrong: cargo publish runs in the package directory and cargo reads the manifest itself. Only the printed link was.

Using the issue's own case, bridge against idlewarden-bridge, the link goes from crates.io/crates/bridge/26.8.27, a real and unrelated crate, to crates.io/crates/idlewarden-bridge/26.8.27.

A panic the tests caught

The obvious implementation is doc["package"]["name"], mirroring how the config code indexes TOML. It compiles, passes the happy path, and panics on a manifest with no [package] table:

a_manifest_with_no_package_table_falls_back_instead_of_panicking ... FAILED
panicked at src/publishers/cargo.rs:175:28: index not found

That is what a workspace root manifest looks like, so this would have turned a cosmetic wrong link into a crash during publish. Now indexed with get() so it falls back instead. I wrote that test because the panic was a suspicion rather than something I had seen, which turned out to be worth the five minutes.

The npm side has no equivalent risk: serde_json::Value::get is already fallible.

Consistent with #961

Same split on the surrounding messages, for the same reason:

• the success URL and the "{name}@{version} already exists on {registry}" line use the crate name, because both make a claim about what is on the registry
• the spawn failure, the transient-retry warning and the final error keep the FerrFlow name, because they identify which of your packages is involved and that is what you would grep your config for

Tests

Six: the issue's case, the workspace-root panic above, an absent manifest, an unparseable one, the already-correct case where both names match, and the URL shape itself.

Verified the main one fails against the old behaviour:

left: "bridge"
right: "idlewarden-bridge"

1241 bin and 945 lib tests passing, clippy clean, wasm surface builds.

[ferrfleet]

Clean fix. published_name() correctly falls back via get() instead of panicking indexing (doc["package"]), and the workspace-root-manifest test proves the panic it avoids. The split between calls that use the manifest name (URL, "already exists") vs. FerrFlow name (spawn failure, retry warning, final error) matches the stated rationale and is consistent with #961. toml_edit is already a workspace dependency, so no new dep risk. Tests cover the real cases: manifest mismatch, no [package] table, absent file, unparseable file, matching names, and URL shape.

Nit: published_name(ctx) re-reads and re-parses Cargo.toml from disk on the success/skip path — negligible here since it's called at most once per run() invocation, not worth optimizing.

No blocking issues.

[github-actions]

SonarQube — aucune nouvelle issue

_{Comparaison entre le projet bac à sable de cette PR et la branche par défaut : SonarQube Community n'analyse pas les PR, ce delta est calculé côté CI. Détail}