[documentation-writing-alignment] Return the full release inventory to version resolution #583

Context and request

The version resolver's Get-GitHubRelease helper declares that it returns all repository releases. Its command uses GitHub CLI's default maximum of 30, so an incomplete inventory can reach version/prerelease decisions. This is a separate runtime/contract correction, not part of the prose-only #582 delivery.

Observed behavior and reproduction

At 64ffb1d87f86bd5d487891fdb140b78385a00531, the helper calls gh release list --json ... without a limit or complete pagination path. Its native help says "all releases". The installed GitHub CLI 2.102.1 help states --limit defaults to 30.

A read-only count probe in this repository returns 30 entries from the default CLI call, while the first REST releases page with per_page=100 contains 100 entries. This establishes truncation; it is not a claim that one REST page is the complete inventory. No version resolver, workflow, publication, cleanup, secret expansion or release mutation is executed by the probe.

$cli = @(gh release list --repo PSModule/Process-PSModule --json tagName | ConvertFrom-Json)
$cli.Count
gh api 'repos/PSModule/Process-PSModule/releases?per_page=100' --jq 'length'

Observed counts: 30 and 100.

Expected behavior

The helper returns every release required by its declared version-resolution contract without silent truncation. An empty repository has an explicit supported empty result; retrieval failure remains distinct from an empty or complete result.

Environment, regression and workaround

Evidence source: the immutable commit above and GitHub CLI 2.102.1 on the Windows execution host. The default CLI maximum is not an OS-specific source behavior. The last complete working implementation is unknown. A larger fixed --limit is not a verified general workaround because repository history can exceed that new cap. Existing version/publication proposals retain their ownership.

Acceptance criteria

• A regression at the helper/caller boundary demonstrates failure with more than 30 controlled releases before the fix and complete results afterward.
• Cases cross actual page boundaries and include a version/prerelease-relevant entry outside the first page. Tests assert returned data and decisions, not implementation text, a specific command spelling or inventory shape.
• The full supported release set is returned with no silent cap; ordering, relevant draft/prerelease handling and empty-repository behavior are explicit and preserve the resolver contract.
• Fetch failure is surfaced through the existing error path, not converted to a partial or empty success-shaped inventory.
• Existing release/version/publication interfaces, source ownership, bump policy, recovery behavior and literal public values remain unchanged unless a separate compatibility decision authorizes change.
• Native help and relevant reference claims match the verified result. A text change from future to present tense or a passing prose check is not evidence of full retrieval.

Technical decisions and implementation plan

The verified root-cause boundary is the helper's unbounded contract versus the CLI default retrieval limit. The supported complete-retrieval mechanism needs source-backed selection and owner coordination with #524 / #359. This issue does not amend those branches or select a version policy. The existing writing changes preserve executable code and leave this finding open.

• Reproduce the incomplete result with a failing controlled helper/caller-boundary regression before implementation.
• Verify the actual retrieval API and choose a complete enumeration mechanism without a new silent cap.
• Implement the smallest root-cause fix with existing failure handling and supported release semantics.
• Run page-boundary, empty/error, and version/prerelease decision regressions plus affected existing checks.
• Update owning native-help/reference claims and retain exact before/after evidence in one focused draft PR; do not merge or alter lifecycle settings as part of this report.