feat(engine): select an exec environment, and put it in the cache key

[raphaelvigee]

Phase 1a of #404, on top of #405. The identity half of exec runners: a target can say which environment it builds in, and that choice reaches hashin. Nothing executes differently yet — #413 opens sessions, #411 carries them across the plugin ABI.

Landing the key change alone is deliberate. It is the part that can silently produce a wrong build, and it is provable without a session existing.

Surface

defaultRunner: //:devenv          # .hephconfig — the expected way to use this

target(name = "build", ..., runner = "//:devenv")   # per-target
target(name = "bootstrap", ..., runner = None)      # opt out

Resolution: per-target → defaultRunner → local. Three levels, not four — runner is deliberately not accepted in transitive, which is dependency-directional: as specified there, adding a dep would silently change a target's execution environment, and a scalar in an additive merge would pick an iteration-order winner.

runner = names a target, not a driver-style name — the one place it differs from driver = sitting beside it, so a bare word is rejected with an error saying why. That it must be a target is the load-bearing choice of the whole feature: only a target has a hashout, and only a hashout reaches the key without inventing a second hash component.

Three decisions worth reviewing

The runner is a hashed: true, runtime: false input — the existing hash_deps shape. That pair is the trick: the environment's hashout reaches the consumer's hashin while its bytes are never materialized into the consumer's sandbox. Materializing would cost a symlink, a list file and an SRC_* entry per target — 20k redundant file ops on a 20k-target build — and would change what an in-sandbox glob matches.

Injected after apply_transitive, not before. A driver's apply_transitive may rebuild def.inputs rather than push to it, and the runner is an engine-level concern no driver is told about. Injecting earlier would leave its presence in the cache key at the mercy of a driver that doesn't know it exists — and its absence is silent, because a target that hashes as though it built on the host is exactly what it would then be. Nothing is lost by being late: collect_transitive_deps filters on runtime, which this input is not.

A runner target with no outputs is rejected. hashin folds input hashouts, and a zero-output target has none — so two runners describing completely different environments would give their consumers byte-identical keys, and an artifact built in one would be served for the other. Folding the runner's own hashin instead would have been a second, runner-shaped hash component; refusing keeps exactly one way for anything to reach the key.

Compatibility

• TargetSpec.runner crosses the provider ABI as an additive string (empty = unauthored, "local" = opt-out, else an addr). A provider that knows nothing about runners is unaffected.
• defaultRunner: needs no rejection path — ConfigYaml is already deny_unknown_fields.
• No cache entry is invalidated: a target with no runner hashes byte-identically to today, asserted by a test.

Tests (crates/e2e/tests/exec_runner.rs, 7 new)

• runner identity reaches the key; two runners ⇒ two keys
• runner = None and no-runner hash identically — the compatibility promise
• the runner artifact is not materialized (no env.json in the sandbox, SRC_/LIST_ empty)
• zero-output runner ⇒ typed error naming the actual problem
• bare name ⇒ rejected with an error explaining a runner is a target
• workspace default applies, and runner = None survives it
• the runner target does not inherit the default (no cycle)

Full local run green: 545 e2e, 183 engine, 91 plugin-exec, plus buildfile/abi. lint clean.

Not in this PR

ExecRunner/open, the session pool, wiring the resolved runner into execution, inspect output, and the devenv cdylib — those are #411 and #413.

_{Stack created with GitHub Stacks CLI • Give Feedback 💬}