fix: stop hardcoding manifest's "." key; dedupe linked-versions changelog repeats

[non7top]

Fixes #20.

Both bugs were found setting up release-please-forecast against a Cargo
workspace using the cargo-workspace + linked-versions plugins
(per-member packages entries, no "." package at all — see
non7top/sort4print#38).

1. current_version/candidate no longer hardcode .

They previously read .release-please-manifest.json at the "." key
unconditionally. A manifest keyed by package path instead (e.g. core,
app, tools/pack-cities) silently came back empty, degrading
bump_type classification and the unreliable_reason gating without
erroring.

Added a package-name input to name the manifest key explicitly. Absent
that, it falls back to the manifest's first key — correct when every
package is kept in lockstep by a linked-versions group with
merge: true, wrong for independently-released packages. Preflight now
warns whenever that fallback is in effect, since it can't tell from the
manifest alone whether the packages are actually linked.

2. Preview comment no longer repeats the changelog body per linked-versions component

Traced to linked-versions with merge: true apparently still walking
one release candidate per linked package internally, each wrapped in an
identical <details><summary>version</summary>…</details> block, before
printing a single combined updates: N line — so the body already
contained the block repeated once per package. Added a defensive
post-process step that collapses immediately-repeated identical
<details> blocks, regardless of root cause.

Verified both fixes with a local git/jq/awk simulation reproducing the
manifest shape and comment body from the linked issue, and confirmed a
regression check that ordinary single-package output passes through the
new dedup step byte-for-byte unchanged.

Test plan

• bash -n over every composite-action run: step
• Unit-tested manifest_version key resolution (. present, .
  absent with fallback, explicit package-name override, empty
  manifest) against representative JSON
• Simulated the full sort4print PR #38 scenario in a throwaway git
  repo (manifest keyed by core/app/tools/pack-cities,
  preview-base at 0.1.0 → preview-head at 0.5.0) and confirmed
  current_version/candidate now resolve instead of coming back
  empty
• Ran the dedup awk against the actual duplicated comment body from
  fix(release): use cargo-workspace + linked-versions plugins sort4print#38 (issuecomment-5844317139) and confirmed it
  collapses to one block
• Confirmed the dedup awk is a no-op (byte-identical output) on a
  real single-package changelog sample from this repo's own history
• Pre-commit hooks (YAML validate, GitHub Actions validate,
  conventional-commit) passed on the commit

[github-actions]

🤖 release-please PREVIEW

What merging this PR into master would trigger:

🤖 I will create a release beep boop

1.5.1 (2026-09-26)

Bug Fixes

• name the simulated merge commit in the previewed changelog (1709a26)
• name the simulated merge commit in the previewed changelog (5a41269)
• stop hardcoding manifest's "." key; dedupe linked-versions changelog repeats (the merge commit GitHub would create for this PR)
• stop hardcoding the manifest's "." key, dedupe linked-versions changelog repeats (f305bc0)

---

This PR was generated with Release Please. See documentation.

_{Two entries, one change: release-please reads both the commit on this branch and the merge commit GitHub will create, whose body is this PR title. Both really do land in the published changelog. Only the merge commit has no SHA to cite, because it does not exist yet.}

_{Predicted from f305bc0 merged into master at 6ccd930, with the PR title read as fix: stop hardcoding manifest's "." key; dedupe linked-versions changelog repeats · Full run}