feat: implement version pinning for JBang aliases

Implements version pinning syntax for aliases using alias:version@catalog
format, allowing users to specify versions at invocation time without
modifying catalog files.

Features:
- Version parsing: Parse alias:version@catalog syntax in Alias.merge()
  - Distinguish GAVs from alias:version using colon counting and dot detection
  - Store version in transient requestedVersion field
  - Validate empty version/alias names and invalid formats

- Property replacement: Support ${jbang.app.version:default} in scriptRefs
  - Uses ProjectBuilder.getContextProperties() for full property context
  - Property replacement takes precedence over automatic replacement
  - Allows: jbang -Dmyprop=xyz myalias:1.2 to use myprop in properties

- Maven GAV version replacement
  - Handle full GAV: group:artifact:version:classifier@type
  - Handle lenient GAV: group:artifact (appends version)
  - Preserve classifier and type when replacing version

- Git URL version replacement for GitHub, GitLab, Bitbucket
  - GitHub: /blob/REF/ and raw.githubusercontent.com/org/repo/REF/
  - GitLab: /-/blob/REF/ and /-/raw/REF/
  - Bitbucket: /src/REF/ and /raw/REF/
  - Safe version substitution with Matcher.quoteReplacement()

- Catalog reference version replacement
  - Pattern: alias@org/repo/REF → alias@org/repo/version
  - Version propagates through alias chains

- Error handling: Hard errors when version specified but no pattern matches

Examples:
  jbang mytool:1.5.0              # Pin version 1.5.0
  jbang mytool:1.5.0@myorg        # Pin version from catalog
  jbang tool:v2.0@org/repo/main   # Pin git-based catalog

Fixes #1979

Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>

Author: maxandersen

docs/modules/ROOT/pages/alias_catalogs.adoc

@@ -98,6 +98,120 @@ The full format is `<alias>@<user/org>(/repository)(/branch)(~path)` or `<alias>
 
 |====
 
+== Version Pinning
+
+Version pinning allows you to specify a version when running an alias, enabling you to use different versions of the same tool without modifying the catalog definition. This is particularly useful for testing, compatibility checks, or using specific versions of tools.
+
+=== Syntax
+
+The version pinning syntax is: `alias:version@catalog`
+
+Examples:
+
+[source,bash]
+----
+jbang mytool:1.5.0@mycatalog      # Pin to version 1.5.0
+jbang tool:v2.0.0@jbangdev        # Pin to v2.0.0 from jbangdev catalog
+jbang app:1.2.3                   # Pin to 1.2.3 from local catalog
+----
+
+=== How It Works
+
+When you specify a version, JBang applies different replacement strategies depending on the alias's script reference:
+
+==== Maven GAV Coordinates
+
+For aliases that reference Maven artifacts, the version replaces the version component in the GAV coordinates:
+
+[source,json]
+----
+{
+  "aliases": {
+    "picocli": {
+      "script-ref": "info.picocli:picocli-codegen:4.6.0"
+    }
+  }
+}
+----
+
+Running `jbang picocli:4.7.0` resolves to `info.picocli:picocli-codegen:4.7.0`
+
+This works with:
+
+- Basic GAV: `group:artifact:version` → `group:artifact:newversion`
+- GAV with classifier: `group:artifact:version:classifier` → `group:artifact:newversion:classifier`
+- GAV with classifier and type: `group:artifact:version:classifier@type` → `group:artifact:newversion:classifier@type`
+- Partial GAV: `group:artifact` → `group:artifact:newversion`
+
+==== Git URLs
+
+For aliases that reference GitHub, GitLab, or Bitbucket URLs, the version replaces the branch/tag/ref in the URL:
+
+*GitHub:*
+
+- `https://github.com/org/repo/blob/main/script.java` + `:v1.0.0` → `https://github.com/org/repo/blob/v1.0.0/script.java`
+- `https://raw.githubusercontent.com/org/repo/main/script.java` + `:v1.0.0` → `https://raw.githubusercontent.com/org/repo/v1.0.0/script.java`
+
+*GitLab:*
+
+- `https://gitlab.com/org/repo/-/blob/develop/script.java` + `:v1.0` → `https://gitlab.com/org/repo/-/blob/v1.0/script.java`
+- `https://gitlab.com/org/repo/-/raw/main/script.java` + `:v1.0` → `https://gitlab.com/org/repo/-/raw/v1.0/script.java`
+
+*Bitbucket:*
+
+- `https://bitbucket.org/org/repo/src/master/script.java` + `:1.0` → `https://bitbucket.org/org/repo/src/1.0/script.java`
+- `https://bitbucket.org/org/repo/raw/master/script.java` + `:1.0` → `https://bitbucket.org/org/repo/raw/1.0/script.java`
+
+==== Property-Based Versioning
+
+For maximum flexibility, aliases can use property placeholders that get replaced when a version is specified:
+
+[source,json]
+----
+{
+  "aliases": {
+    "quarkus": {
+      "script-ref": "io.quarkus:quarkus-cli:${jbang.app.version:3.0.0}"
+    },
+    "example": {
+      "script-ref": "https://github.com/org/repo/blob/${jbang.app.version:main}/script.java"
+    }
+  }
+}
+----
+
+Running `jbang quarkus:3.5.0` resolves to `io.quarkus:quarkus-cli:3.5.0`
+
+Running `jbang example:v2.0` resolves to `https://github.com/org/repo/blob/v2.0/script.java`
+
+If no version is specified, the default value (after the colon) is used.
+
+NOTE: Property replacement takes precedence over automatic version replacement. If your alias uses `${jbang.app.version}`, automatic replacement is skipped.
+
+==== Alias Chains
+
+Version pinning works through alias chains. If an alias references another alias, the version propagates through the chain:
+
+[source,json]
+----
+{
+  "aliases": {
+    "base-tool": {
+      "script-ref": "com.example:tool:1.0.0"
+    },
+    "tool": {
+      "script-ref": "base-tool"
+    }
+  }
+}
+----
+
+Running `jbang tool:2.0.0` resolves all the way through to `com.example:tool:2.0.0`
+
+=== Backward Compatibility
+
+Aliases without version pinning work exactly as before. The version syntax is entirely optional and doesn't affect existing usage.
+
 == Local Alias Catalogs
 
 JBang will also look in the current directory for a `jbang-catalog.json` file and if it exists it will look up any aliases