ChangeLog feature in GenHub

[undead2146]

User Story

As a GenHub user or contributor,
I want to see a structured list of features, fixes, and architectural changes derived from Pull Requests,
so that I can track the progress of the Development branch and understand exactly what has changed between official releases on Main.

---

Description

Currently, GenHub presents official release notes when a build is promoted to the Main branch. However, a significant amount of development happens in the Development branch through PRs that may not be immediately reflected in a release.

This feature aims to create a "Smart Changelog" that interacts with the GitHub API to fetch merged Pull Requests. It should compare the current application version against the state of the repository, extracting PR titles and descriptions. The logic must be "smart"—meaning it shouldn't just list a raw log, but categorize changes based on GitHub labels (e.g., feature, fix, refactor) to provide a structured overview.

---

Acceptance Criteria

• API Integration: Extend OctokitGitHubApiClient to fetch merged Pull Requests between two specific Git tags or commit hashes.
• PR-to-Changelog Mapper: A service logic that parses PR titles and bodies (using Markdown) and categorizes them into groups: Features, Bug Fixes, Architectural Changes, and Internal/Refactors.
• Development Tracking: The UI must be able to show "Incoming Changes" (PRs merged into Development but not yet in an official Main release).
• Smart Deduplication: Ensure that if multiple PRs are part of a single large feature (Epic), they are grouped logically or nested.
• UI Display: Integrate this data into the "Changes" strip of the NewsFeed Tab (Issue Set up build workflow #14) and a dedicated "Full Changelog" view. (A popup with ChangeLogsWindow is also sufficient)
• Caching: Results should be cached via IDynamicContentCache to avoid hitting GitHub API rate limits on every app launch.

---

Technical Notes

• Models/Interfaces:
  • Utilize IGitHubApiClient to interface with Octokit.
  • Create a ChangelogEntry model to store parsed PR data.
  • Use SemVerComparator to determine the delta between the current assembly version and remote tags.
• GitHub Logic:
  • Query GET /repos/{owner}/{repo}/pulls with state=closed and base=development or base=main.
  • Use PR labels to drive the "Smart" categorization. (e.g., PRs labeled enhancement go to "Features").
• MVVM Requirements:
  • Implement ChangelogViewModel to handle the asynchronous loading state.
  • The View should support Markdown rendering (using a library like Avalonia.HtmlRenderer or similar) to correctly display PR descriptions.
• Edge Cases:
  • Handling PRs without descriptions.
  • Fallback logic when the GitHub API is unreachable or rate-limited.

---