Are Rollup content hashes a safe caching contract across major upgrades?

We use Rollup's output.entryFileNames and chunkFileNames with [hash] placeholders so browsers and our CDN can cache emitted chunks long-term. This works well within a single Rollup version, but we are unsure what guarantees exist when we upgrade.

The documentation describes how hashes are generated from chunk content, but I cannot find a clear statement about whether the hashing algorithm, chunk-splitting heuristics, or default output formats are stable across major versions (for example 3.x to 4.x). If an identical source tree produces different chunk boundaries or different hashes after an upgrade, every cached URL changes at once, which effectively invalidates our long-term caching strategy and complicates comparing pre- and post-upgrade builds.

We pin the exact Rollup version and commit our lockfile, so rollback itself is not the concern; the concern is knowing which parts of the emitted output we can treat as a contract.

Is chunk content hashing documented as stable across major versions, or explicitly not guaranteed? Are chunk-splitting decisions part of any stability guarantee, or only the plugin hook API? What do teams relying on long-term caching typically diff (file names, hashes, warnings) to verify an upgrade is output-equivalent before shipping it?