fix: add short TTL for Hermit self-update binary

[jrobotham-square]

Problem

The Hermit binary URL (hermit-{os}-{arch}.gz) is mutable — the same URL serves different versions as Hermit is updated. Cachew caches this binary with the global max-ttl (24h disk / 72h S3), which means hermit update --self-update fetches a stale version from Cachew's cache, causing workstations to downgrade Hermit even when the Docker image has the correct version baked in.

We observed this in staging: the Docker image had Hermit v0.52.1, but hermit update downloaded v0.50.1 through Cachew's cache.

Fix

Adds a configurable binary-ttl (default 1h) to the Hermit strategy that applies a shorter cache TTL specifically to the Hermit self-update binary (hermit-{os}-{arch}.gz). Versioned package downloads continue to use the default (long) TTL since their URLs are content-addressed.

Config

No config changes required — the default 1h TTL is used. Can be overridden in cachew.hcl:

strategy hermit {
  binary-ttl = "30m"
}