Revisit whether pack version field is needed

[bguidolim]

Context

The version field in techpack.yaml is currently used for:

• Display: log messages, mcs pack list, section markers (<!-- mcs:begin ios v2.0.1 -->)
• Peer dependency checks: SemVer.isCompatible() enforces minVersion constraints between packs
• Lockfile mismatch reporting: shows version alongside SHA

However, all actual pinning and reproducibility is commitSHA-driven. The lockfile pins by commit hash, mcs sync --lock checks out by commit hash, and mismatch detection compares commit hashes.

This means:

• A pack author can push new commits without bumping the version — the system still works correctly
• A version bump without a new commit has no effect
• The version in section markers is actually MCSVersion.current (the tool version), not the pack version

Questions to resolve

1. Is the version field pulling its weight, or is it just noise?
2. Should pinning use version tags instead of (or in addition to) raw commit SHAs?
3. If we keep it, should mcs pack update warn when the commit changed but the version didn't?
4. The only functional use is peer dependency minVersion — could that use git tags instead?

References

• PR Support local packs and GitHub shorthand (#81, #82) #143: Local packs and GitHub shorthand (Support local packs without file:// URL (direct path reading) #81, Support username/repo shorthand for GitHub-hosted tech packs #82)
• Sources/mcs/ExternalPack/ExternalPackLoader.swift — peer dependency checks
• Sources/mcs/Templates/TemplateComposer.swift — section markers use MCSVersion.current, not pack version
• Sources/mcs/Doctor/SectionValidator.swift — staleness uses content hash, not version