[Feature request] Propagate semver version comments for SHA-pinned actions in generated CI

## Problem

When pinning GitHub Actions to commit SHAs via `github-action-commits`, the generated `release.yml` has no way to include the corresponding semver version as a YAML comment:

```yaml
# generated output
uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd

# desired output
uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2
```

Users naturally annotate the SHA with a comment in `dist-workspace.toml`, but the parser discards it. This makes the generated workflow harder to audit since reviewers and tools cannot tell what version a SHA corresponds to at a glance.

## Proposed solutions

### Option A: Structured config value

Accept a table in addition to a plain string:

```toml
[dist.github-action-commits]
# existing format still works
"actions/upload-artifact" = "ea165f8d65b6e75b540449e92b4886f43607fa02"

# new format with version annotation
"actions/checkout" = { commit = "de0fac2e4500dabe0009e67214ff5f5447ce83dd", version = "v6.0.2" }
```

When `version` is present, the generated YAML appends it as a comment on the `uses:` line. Backwards compatible: the value deserializes as an enum accepting either a plain string or a table.

### Option B: Auto-resolve from GitHub API

At `dist generate` time, resolve the SHA to its corresponding semver tag via the GitHub API and append the comment automatically. Works with the current config format but introduces a network dependency during generation.

Start at the github-action-commits configuration and the dist generate entry point, then trace how dist-workspace.toml values become generated release.yml. Compare the proposed structured value and API-based approach, including backward compatibility. Done means generated SHA-pinned uses lines can carry the corresponding semver comment without breaking existing plain-string configuration.

Written by the indexing model from the issue text.