Summary

Improves the bump-upstream GitHub Action to correctly handle upstream repos that use non-standard version tag formats (e.g., n8n@2.10.3, v1.2.3) and ensures the version written to the manifest and docker-compose matches what the Docker image registry actually expects.

Changes

• Semver-based release sorting: Instead of relying on GitHub API ordering (releases[0]), releases are now filtered (no drafts, prereleases, or RCs) and sorted by semver to always pick the highest valid version.
• Tag prefix handling for validation: isValidRelease now strips prefixes before semver validation, so tags like n8n@2.10.3 are correctly recognized as valid releases instead of triggering false warnings.
• Docker registry version format resolution (resolveVersionFormat.ts): New helper that determines the correct version format by:
  1. Parsing the package's Dockerfile to find which Docker image uses the build arg
  2. Checking the Docker registry (Docker Hub, ghcr.io, gcr.io) to see if the stripped version exists as a tag
  3. Returning the format that matches the registry (e.g., v1.17.1 for geth, 0.17.7 for ollama, 2.10.3 for n8n)
• Increased per_page to 100 for GitHub releases API to ensure we don't miss the latest valid release.
• DX improvements: Added VSCode debug launch config docs and cli/start npm scripts.

Problem

Different upstream projects use different conventions:

Previously, the raw GitHub tag was always used, which could cause mismatches with Docker image tags, or the sort order could pick the wrong release.

Test plan

• Verify version resolution with geth (v prefix kept — Docker tag uses v)
• Verify version resolution with ollama (v prefix stripped — Docker tag has no v)
• Verify version resolution with n8n (n8n@ prefix stripped — Docker tag is bare semver)
• Verify semver sorting picks highest version when releases are out of order
• Verify isValidRelease no longer warns for n8n@X.Y.Z style tags
• Verify fallback behavior when Docker registry is unreachable (keeps original tag)