fix(source-files): key document cache on content hash, not mtime

[marcleblanc2]

Problem

@contentlayer2/source-files keys its document cache on the file's mtime:

const documentHash = yield* $(pipe(fs.stat(fullFilePath), T.map((_) => _.mtime.getTime().toString())))

Git doesn't store mtimes, so every fresh clone (Vercel, GitHub Actions, Netlify, …) stamps all content files with the checkout time. Even when .contentlayer/.cache is persisted between builds, no stored documentHash ever matches, and every document is re-parsed and re-rendered on every CI build. The cache only ever hits on a working tree that persists between runs (a developer laptop).

We hit this on a ~500-document Next.js site: after wiring the cache dir into Vercel's build cache, the cache loaded fine but was then 100% ignored.

Fix

Read the file once, hash its contents with the existing hashObject (xxhash64 from @contentlayer2/utils, already used for the schema hash), and pass the contents to processRawContent so a miss doesn't read the file twice.

• documentHash is now stable across clones and only changes when the content changes.
• processRawContent no longer needs fs.HasFs; fs.StatError is no longer possible, HashError is mapped to UnexpectedError like the other IO errors.
• generate-dotpkg also uses documentHash to skip unchanged .json writes, so it benefits from the same stability.
• Updated the stale DataCache.CacheItem doc comment that still described the mtime scheme.
• Changeset: patch for @contentlayer2/source-files and @contentlayer2/core.

Cache entries written by previous versions have mtime-shaped hashes and will miss once, then be rewritten with content hashes. Nothing else about the cache format changes.

Tests

Added to makeCacheItemFromFilePath.spec.ts (runTest gained an optional previousCache):

• documentHash depends on file contents, not mtime — bumps the fixture's mtime by an hour with utimes and asserts the hash is unchanged, and that a file with different content gets a different hash. Fails on main (expected '1789625945676' to be '1789622345676'), passes with this change.
• returns the previous cache item when the hash matches — marks the cached document and asserts the marker comes back.
• re-parses the document when the hash differs — stale hash in previousCache → marker absent, fresh hash returned.

yarn build:ts, yarn lint:check, and yarn test (all workspaces) pass locally.

Also verified end to end with the built CLI on a scratch project: after touch -t 203001010000 content/*.md the persisted data-*.json hashes are byte-identical; editing one file changes only that file's hash.