Bug: Issue Archiving Logic Incorrectly Buckets Recently Closed Issues

During testing of the sync_issues tool, a bug was discovered in the logic that determines the file path for closed issues. The SyncService was incorrectly moving recently closed issues (i.e., issues closed after the latest release) into a fallback unversioned archive folder.

The correct behavior should be for these issues to remain in the main .github/ISSUES directory, alongside open issues, until a new release is published. An issue should only be considered "archived" once a subsequent release has been created.

Root Cause

The #getIssuePath method in SyncService.mjs had two flaws:

1. The release list was sorted in descending order, causing the .find() method to select the latest possible release instead of the next chronological one.
2. The logic had a fallback that would move any closed issue that didn't match a release into an archive folder (unversioned), instead of leaving it in the active issues directory.

Resolution

The #getIssuePath method was refactored with the following logic:

1. Correct Sort Order: The release list fetched by #fetchAndCacheReleases is now sorted in ascending (chronological) order.
2. Improved Archiving Logic:
   • An issue with a milestone is still archived immediately under that milestone when closed.
   • A closed issue without a milestone is now handled correctly:
     • If a release is found that was published after the issue was closed, the issue is moved to that release's archive folder.
     • If no subsequent release is found, the issue correctly remains in the main .github/ISSUES directory.

This ensures that the local file structure accurately reflects the development lifecycle, where closed issues are only archived after they have been included in a release.