Manifest lookup hardcodes the "." key; preview body likely duplicates per linked-versions component #20

Found both of these while setting up sort4print's release-please pipeline for a Cargo workspace using the cargo-workspace + linked-versions plugins (per-member packages entries, no "." package at all — see non7top/sort4print#38).

1. Confirmed: current_version/candidate hardcode the manifest's "." key

action.yml (around the "Extract predicted version" step):

current_version=$(git show preview-base:.release-please-manifest.json | jq -r '."." // empty')
...
candidate=$(git show preview-head:.release-please-manifest.json | jq -r '."." // empty')

For a repo whose .release-please-manifest.json has no "." key — e.g. ours, now keyed by package path (core, app, tools/pack-cities, tools/pack-flags) after switching to the cargo-workspace/linked-versions plugins for a pure virtual workspace root — both of these silently come back empty. That degrades bump_type classification and the unreliable_reason gating without erroring, rather than failing loudly or falling back to something sensible (e.g. the first key, or a configurable package name).

Reproduced against: non7top/sort4print#38, run https://github.com/non7top/sort4print/actions/runs/36227351998

2. Likely: the preview comment repeats the same changelog body once per linked-versions component

The posted preview comment on that same PR (non7top/sort4print#38 (comment)) shows the identical <details><summary>0.5.0</summary>... block four times in a row — once too many for a repo with 4 packages linked via linked-versions with merge: true into what should read as one release.

Traced the assembly logic (the "Build the body of the preview comment" step): it does a single cat trimmed-output.txt with no loop, and trimmed-output.txt is produced by an awk script that starts capturing at every ^body: line and stops at ^updates: [0-9]+$. So the duplication is already present in dryrun-output.txt — i.e. in npx release-please release-pr --dry-run's own stdout — before this tool touches it. My best guess, not verified against release-please's own source: linked-versions with merge: true still walks one release candidate per linked package internally, each with an identical body, before printing a single combined updates: N line.

If that guess holds, this isn't really a release-please-forecast bug so much as this tool faithfully relaying an upstream oddity — but it might be worth having the awk capture (or a post-process step) deduplicate identical consecutive body: blocks defensively regardless of root cause, since the rendered comment reads badly either way.