Native resolver serves a stale cached 'latest' binary forever

Start with pamica/native/resolver.py:119-121 and the pamica.native.resolver.resolve() entry point to understand the cache-hit path and decide between the proposed resolution strategies. Review validate_implementations.py and the validation guide's v0.3.3 pin. Done means an older cached "latest" is not served after a newer tag is known, the selected tag and SHA-256 are logged, and the proposed cache or tag-resolution test passes.

Found during epic #324 Phase 6 while running validate_implementations.py against the native reference binary.

Symptom

pamica.native.resolver.resolve() with the default version="latest" returns whatever binary was cached the first time "latest" was resolved on this machine, forever. On the development host, ~/.cache/pamica/bin/latest/ holds a binary downloaded on 2026-08-15 whose SHA-256 differs from the current v0.3.3 release asset. It happens to produce the same log-likelihood on the bundled sample, but nothing guarantees that for the next release, and the user has no signal that the "latest" binary is stale.

Root cause

pamica/native/resolver.py:119-121: the cache path is <cache>/<version>/<asset>, and a hit returns immediately without any check. For a pinned tag this is correct (a release asset never changes). For "latest", the directory name is a moving alias, so the first download is served indefinitely, and the SHA-256 is only verified at download time.

Options (decision needed)

• Resolve "latest" to a concrete tag (GitHub releases/latest API or the redirect target) and cache under that tag, so a new release is fetched once and the old one stays addressable; fall back to the newest cached tag when offline, with a warning.
• Or: key pamica.native to the installed pamica version by default (the binary built for this release), and make "latest" explicit opt-in.
• Either way, log which tag/SHA-256 is being used, so parity reports can name the reference exactly (the validation guide already pins the v0.3.3 binary for its per-backend table).
• Test: a cached "latest" from an older tag is not served once a newer tag is known (network-gated test, or an offline test on the tag-resolution function).