lc run: rule params include git_sha/lc_version, so any commit re-materialises every output

[rpaviot]

What happened

The generated Snakefile passes the whole per-output cfg dict as the rule's params, and lc run uses
--rerun-triggers code,input,mtime,params. The dict contains git_sha (and lc_version) next to
code_version, so after any new commit — even a README-only one — the next lc run reports
"Params have changed since last execution", deletes the output directories it targets and re-runs them.
lc status and lc verify compute staleness from code_version (recipe + image identity + decisions)
and keep reporting those outputs as ok, so the two views disagree, and a 24 h fit can be silently
redone. The comment in engine/snakefile.py around the cfg[rule_key][u] = {...} block says the
params trigger is meant to fire on code_version drift.

Error

reason: Params have changed since last execution: Union of exclusive params before and now across all output: before: {'code_version': 'sha256:...', ..., 'git_sha': '<old sha>', ...}

.snakemake/metadata/<output> stores the params record with the sha in it.

Reproduction

1. lc run some_output --universe baseline (materialises it; lc status -> ok)
2. git commit --allow-empty -m x
3. lc run some_output --universe baseline -> the rule is re-run with the reason above; lc status still said ok before the run.

Workaround used: lc run ... --rerun-triggers code,input,mtime after commit-only changes.

Environment

• ASTRA: 0.2.11
• lightcone-cli: 0.4.2
• Python: 3.12.8
• OS: Linux 4.18 (RHEL 8, SLURM cluster, container runtime: none)