When does Jest's transform cache serve stale output from a custom transformer that reads external files?

I'm designing a custom Jest transformer (Jest 29) that inlines values from a shared config file at transform time. My understanding is that Jest's on-disk transform cache keys entries by the source file's content hash, the transformer's own code, the Jest version, and parts of the config — but not by arbitrary files the transformer happens to read.

That suggests editing only the external config file would leave the old transformed output in place, since nothing in the cache key changes. I want to confirm exactly which inputs participate in the key, and what the supported mechanism is for extending it (for example, getCacheKey on a custom transformer) versus relying on jest --clearCache in CI.

I'm also unsure how this interacts with the jest-haste-map cache, which is a separate layer tracking the module map rather than transformed code.

Specifically:

• Which inputs are guaranteed to be part of the default transform cache key in Jest 29?
• Is implementing getCacheKey (hashing the external file's contents) the documented way to invalidate on external-state changes, or is there a config-level alternative?
• Can the haste-map cache independently cause stale module resolution after files are copied into a CI workspace, and does installing Watchman change that behavior?