Function preprocess_pack 

pub fn preprocess_pack(
    entries: Vec<PackEntry>,
    registry: &PreprocessorRegistry,
    pack: &Pack,
    fs: &dyn Fs,
    datastore: &dyn DataStore,
    paths: &dyn Pather,
    mode: PreprocessMode,
    force: bool,
) -> Result<PreprocessResult>

Run the preprocessing pipeline for a pack’s file entries.

1. Partition entries into preprocessor files vs regular files.
2. In PreprocessMode::Active (real dodot up runs): for each preprocessor file, expand, write results to datastore (unless the deployed file has diverged from the cached baseline — see step 5), write the baseline cache record.
3. Create virtual PackEntrys pointing to the datastore files.
4. Check for collisions between virtual and regular entries.
5. Divergence guard (Active only): unless force is true, compare the prospective deployed file against the cached baseline before overwriting. When the deployed bytes have changed (the user edited the deployed file directly), skip the write and record a SkippedRender so the caller can warn the user. See docs/proposals/preprocessing-pipeline.lex §6.4.
6. In PreprocessMode::Passive (dodot status, up --dry-run): skip every disk-mutating step. Sources are never read for marker scans; preprocessors are never invoked (no provider calls); the datastore is not touched. Virtual entries are still produced so the rest of the planner can compute intents — their bytes come from baseline.rendered_content when a baseline exists. First-time pack templates with no baseline still surface a placeholder virtual entry (so dodot status can render them as “pending” under the stripped name) but with empty rendered_bytes. Handlers that need rendered content for sentinel hashing (install, homebrew) skip intent generation for those placeholders rather than erroring out — the next real dodot up plans them normally. See PreprocessMode and docs/proposals/secrets.lex §7.4.
7. Return the result for merging into the handler pipeline.

Set force = true to bypass the divergence guard. Surfaces as dodot up --force in the CLI; needed when the user knows they want to overwrite a divergent deployed file (e.g. after rotating an env var that a template references). Ignored in Passive mode (no writes happen there at all).