Support capture-group tag sorting for non-GitHub sources

[kergoth]

Summary

For non-GitHub tag discovery, the current ordering strategy can be too dependent on whole-string semver parsing. Some upstream tag formats are better described by a regex with meaningful capture groups.

Problem

If a tag_pattern regex already defines the meaningful version components, the sort logic should be able to use those captured groups directly instead of attempting to interpret the full tag string as a semver-like value.

Proposal

If tag_pattern contains capture groups:

• use each captured group as one sort field
• attempt integer comparison for a group when it parses cleanly as an integer
• otherwise compare that group lexicographically

This would make ordering more flexible for upstreams whose tags do not fit standard semver parsing.

Done looks like

• Capture groups in tag_pattern are detected and used as the ordering key for relevant non-GitHub sources.
• Numeric groups sort numerically.
• Non-numeric groups sort lexicographically.
• Existing behavior remains intact for sources without capture groups.

Open question

A reasonable fallback alternative is ordering by tag date or commit date instead of tag name. That approach may be simpler and more universal, but it also changes the semantics of what "latest" means. This issue should explicitly decide whether that alternative is needed, instead of letting it remain implicit.

[kergoth]

While this makes sense, it adds complexity. I think the best bet is to review the existing git resources to determine if any use non-semver-compatible versioning first. If not, YAGNI, and we punt until it's needed. The key here is ensuring that the failure mode isn't just silently using the wrong tag/version, we need to explicitly check for and fail out if we run into semver-incompatible version strings. That needs to be done before I'd consider closing this as not implementing for now.