Disambiguate release changelog asset labels

[PrzemyslawKlys]

Summary

• append the release tag to changelog asset link labels when the asset filename does not already include it
• keep already-versioned asset labels unchanged
• add regression coverage for repeated IntelligenceX reviewer asset names across releases

Tests

• dotnet test .\PowerForge.Tests\PowerForge.Tests.csproj -c Release --filter "FullyQualifiedName~WebReleaseHubRenderingTests" /nr:false

[claude]

Code Review

Overview

This PR fixes a usability issue where multiple releases sharing an identically-named asset (e.g. IntelligenceX.Reviewer-linux-x64.zip) produce indistinguishable links in the changelog view. The fix appends the release tag in parentheses when disambiguation is needed.

---

Code Quality — ReleaseHubRenderer.cs

Positive:

• ResolveChangelogAssetLabel is clean, focused, and well-named.
• XSS safety is preserved: Html(ResolveChangelogAssetLabel(...)) keeps the escape wrapper in place.
• The "Download" fallback mirrors the existing pattern in RenderReleaseButtons (line 202).
• StringComparison.OrdinalIgnoreCase is the right choice for filename/tag matching.

Minor issues:

1. Null-conditional on a non-nullable property — ReleaseHubReleaseView.Tag is declared string Tag { get; init; } = string.Empty; (non-nullable). The ?.Trim() on line 857 works fine at runtime but the ? is misleading — it implies the property could be null when it cannot. Consider release.Tag.Trim() instead, or annotate the field string? if it can genuinely be absent.

2. Consistency gap with RenderReleaseButtons — The buttons rendering (lines 201–210) separates the tag into a dedicated <span class="pf-release-button-meta"> element, giving CSS full control over its presentation. The changelog path inlines the tag as plain text (tag). This is probably intentional given the different rendering context, but worth a short comment if the two paths are expected to stay diverged.

---

Test Coverage — WebReleaseHubRenderingTests.cs

Positive:

• The new test covers the primary scenario well: two releases, same asset name, both labels disambiguated, no bare untagged link.
• The DoesNotContain(">IntelligenceX.Reviewer-linux-x64.zip</a>") assertion is a good negative check.

Gaps:

3. "Already-versioned" path is untested — The PR description explicitly states "keep already-versioned asset labels unchanged", but there is no test exercising name.Contains(tag, OrdinalIgnoreCase) == true. A release whose asset is named IntelligenceX.Reviewer-linux-x64-reviewer-20260419115614.zip (tag embedded in filename) should render without the appended (tag). Without a test, a future refactor could silently break this promise.

4. null/empty tag branch is untested — The string.IsNullOrWhiteSpace(tag) guard has no coverage. If a release with a blank Tag is valid input, a test or a comment explaining why it cannot occur would be helpful.

---

Summary

The fix is correct and the approach is sound. Two concrete suggestions before merge:

• Add a test for the already-versioned case (asset filename already contains the tag → no (tag) suffix appended).
• Either remove the ?. on release.Tag or change the property to string? to match actual nullability intent.

Everything else looks good.