[BUG] apm install rewrites generated_at on every run when SHA-pinned deps carry resolved_tag (lockfile_version mismatch) #3433

Version: 0.33.0 (18c4c43); the same code is on main today.

What happens
On a project whose committed apm.lock.yaml has lockfile_version: '2' because some SHA-pinned dependencies carry resolved_tag, every apm install (no dependency change) rewrites the lock: only generated_at changes, so git status is dirty after each install.

Cause

1. The install builds the new lock in memory without resolved_tag, so its lockfile_version is '1'.
2. _preserve_existing_revision_pin_tags (src/apm_cli/install/phases/lockfile.py) then copies resolved_tag back onto unchanged SHA-pinned entries by setting dep.resolved_tag directly, without re-deriving lockfile_version (only add_dependency promotes it).
3. _write_if_changed calls LockFile.is_semantically_equivalent, which compares lockfile_version first (src/apm_cli/deps/lockfile.py): '1' != '2', so it returns False and the lock is saved with a new generated_at. All dependency, MCP and LSP fields compare equal.

Reproduce
A lock with at least one dependency pinned by commit SHA whose entry has resolved_tag (written when that commit matches a tag), committed as lockfile_version: '2'. Run apm install twice: the second run rewrites generated_at.

Suggested fix
Re-derive lockfile_version (or call the same promotion logic as add_dependency) after _preserve_existing_revision_pin_tags, or have is_semantically_equivalent compare the version each lock would require for its contents rather than the stored field.

Workaround and its problem
Regenerating the lock from scratch avoids the mismatch, but drops MCP ownership records for already-committed configs, as in #3090.