fix(publishers): report the npm package name from package.json, not the ferrflow name

[BryanFRD]

Closes #954.

The npm publisher reported a success URL built from the FerrFlow package name rather than the name npm actually published under. published_name now reads name from the package's package.json, falling back to the FerrFlow name when the manifest cannot be read.

The publish itself was never wrong: npm publish runs with current_dir(ctx.package_path) and npm reads the manifest itself. Only what FerrFlow printed afterwards was.

Why it matters more than a cosmetic link

As the issue set out, the mismatch is the monorepo default rather than an edge case: a short FerrFlow name (site, api, core) against a scoped npm name (@acme/site). Those short names are all taken on npm, so the wrong URL points at a stranger's package instead of 404ing, which is the failure mode nobody notices.

One judgement call beyond the issue

The issue flagged the Skipped and error messages as "labels rather than identifiers" and asked for a second opinion. I changed one of the two.

"{name}@{version} already exists on {registry}" is a claim about what is on the registry, so it has to use the npm name. Saying site@1.0.0 already exists on npm when the package is @acme/site sends the reader to check the wrong package, which is the same defect as the URL wearing different clothes.

The error line "npm publish failed for {}" I left on the FerrFlow name. It identifies which of your packages failed, and the FerrFlow name is what you would grep your config for.

Tests

Five, covering the scoped case from the issue, the literal @ and / in the URL (npmjs.com wants @acme/site, not percent-encoded), and both fallbacks: no manifest, and a manifest with no name. Plus the already-correct case where the two names match, so the fix cannot regress it.

Verified the main test fails against the old behaviour:

the_published_name_comes_from_package_json_not_the_ferrflow_name ... FAILED
  left: "site"
 right: "@acme/site"

1235 bin and 939 lib tests passing, clippy clean, wasm surface builds.

Not in this PR

#948 is the same defect in the cargo publisher. It touches a different file and reads a different manifest format, so it stays its own change, as that issue and this one both say. Worth doing next since the reasoning is now settled.

[ferrfleet]

Clean, well-scoped fix. published_name correctly reads package.json from ctx.package_path (matching where npm publish actually runs), falls back safely on unreadable manifest / missing name / non-string name, and the scoped-name URL (@acme/site) is left unencoded, matching npmjs.com's actual URL format. Good call keeping the npm publish failed for {} line on the FerrFlow name (that's what you'd grep your config for) while switching the URL and "already exists" message to the npm name — both are consistent with what each message is claiming. Tests cover the scoped case, both fallbacks, and the already-matching case. Nothing blocking.

[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}