Memoized CI

`zev-ci` can skip re-running a pipeline step entirely when it has already run, successfully, against the exact same inputs. ## What counts as "the same inputs" A cache key is computed from three things: a deterministic hash of the entire source tree the step runs against (every file's path and content, sorted for determinism, so two directories with identical files always hash identically regardless of filesystem walk order), the step's container image, and the step's exact command. If all three match a previous, successful run, the step is skipped. ## Why only successful runs are cached A failed or timed-out run is never memoized. The same content could genuinely produce a different outcome on a re-run — flaky tests, transient environment issues — and treating a failure as permanently cached would hide an ongoing, real problem from every future run rather than surface it. ## A real, measured result Running the same pipeline step twice against identical source: the first run genuinely executes in Docker and takes 0.53 seconds. The second run is served entirely from cache — Docker is never invoked — and takes 0.01 seconds. Changing the source and running a third time correctly triggers real re-execution again, reflecting the new content. ``` === RUN 1 (genuinely executes) === exit_code=0 === RUN 2, identical source (memoized) === (memoized: identical source+image+command previously succeeded, skipping execution) exit_code=0 === RUN 3, changed source (genuinely re-executes) === exit_code=0 ``` ## Where the cache lives Cached results are stored as simple binary files on the CI host, keyed by the computed hash — a length-prefixed format for exit code, timeout flag, stdout, and stderr, avoiding any text-escaping complexity for arbitrary binary output. This is wired directly into the real pipeline execution path used by both the production `zev-ci` service and the `zev-ci-local` command, which runs the identical pipeline definition locally before you push.