feat(plugin-abi): exec runners as a first-class plugin component

[raphaelvigee]

On top of #416. Exec runners become a first-class plugin component.

A plugin can now export an exec runner beside its provider, drivers and hooks.
The host asks it to open a session and gets back a live session object; it
then asks that session to transform every spawn's spec. So a runner can hold
one devenv shell open and route every target's exec through it, deciding per
spawn rather than once per environment. That is the point: how a process starts
belongs to the runner.

Why a component, and not methods on ManagedDriver

The first draft of this PR rode new DriverMethod ids. That was additive and
free — and the wrong shape. The code said so:

• A runner is not a driver. It does not parse, build, or carry a config
  schema. Every runner had to stub parse / apply_transitive / run — three
  dead methods per implementor, 22 stub lines across two test doubles alone.
• A runner-only plugin was impossible. Those methods are defaultless, so
  shipping a docker runner meant inventing a dummy driver that builds nothing.
• A runner's name was a driver's name. A cdylib could only serve runners for
  its own driver, so a docker runner could not serve targets built by bash.
• It was undiscoverable. PluginComponents is the map of what a plugin
  exports; a runner hidden behind method ids was not in it.

The session is an object, not an id

The second draft got the component right and the session wrong. It defined an
id-keyed protocol — open_session / prepare_spec(id, …) / close_session(id)
— on the premise, written into exec-runner's own module docs, that "an
ExecSession is a live object; that cannot cross a stable boundary."

That premise is false, and the counter-example was 240 lines above it in the
same file: ResultOutcome.artifacts is an SVec<DynArtifact>, live trait
objects returned from a method across this exact seam. A cdylib is dlopened
into this process — same address space, same fd table — so a trait object
crosses as a fat pointer and stays live on the plugin's side. The ids were
routing around a boundary that is not there, and the cost landed on every
implementor: each had to keep its own HashMap<String, Session> so it could
answer by a name the host had invented for it.

So open returns a DynExecSession, and this goes away:

• ExecRunnerPlugin, the plugin-side variant of the trait. A cdylib runner
  now implements the same ExecRunner a host-side one does — no adapter, no
  second set of semantics to keep in step.
• PluginExecRunner / PluginSession — all of exec-runner/src/plugin.rs.
• OpenedSession, and session_id on every request.
• The host-side session registry, and the plugin-side one each runner kept.

plugin-devenv shows the effect: Runner is one field again, its
Mutex<HashMap<…>> and its AtomicU64 id counter both deleted.

A plugin driver does not create its own processes

A driver compiled into heph holds the session and creates its processes. A
driver in a cdylib cannot — same reason as above: a session is a live object and
the plugin links its own copy of every type.

An earlier draft of this PR sent the session's environment to the guest and
had it rebuild a stand-in. That is exact for Local and Env and silently
wrong for anything that also rewrites the command: under mode = "session" a
plugin driver would run its target on the host with the shell's variables
applied, never entering the shell, while still echoing runner_key back — past
the very ack that exists to catch a degraded run.

So the driver asks the host to create the process (StableExecService), and
the host applies the real session in full. Nothing about the session crosses,
and every runner mode works for every driver — go_* targets build inside an
oci_runner container like anything else.

DynExecService rides run exactly as a DynExecutor rides a provider's
list; that precedent is why it is a parameter rather than a global. Its body
is spawned on the host runtime via SeamSpawn, because the future is polled by
a guest worker and creating a process touches the host reactor — doing that
with no host runtime context panics, and a panic at the extern seam aborts.

Two scope calls, documented at the code:

• No runner → LocalSession in the guest. The common path stays in-process
  with no round trip.
• Batch only across the seam. Nine of the ten plugin-side call sites are
  batch already; the tenth (docker_build showing buildx progress) loses
  liveness only when itself under a runner.

The end-to-end test earned its place immediately — it failed on the first run
with empty stdout, because ExecSpecPatch deliberately carries no stdio and the
host rebuilt the spec with defaults. The runner lane hides that by re-applying
the host's own stdio; this lane has none to re-apply and must be told the kind.
A unit test on argv would have passed while the feature was broken.

The ABI break

StableExecRunner / DynExecRunner / NamedExecRunner / StableExecSession /
DynExecSession / OpenOutcome, and PluginComponents.runners. ABI_SEMVER
0.5.0 → 0.6.0 — a layout change to the create-entry struct, exactly as
0.3.0's hooks was, so every plugin is rebuilt against it. All three in-tree
plugins declare the new field here, and scripts/abi-check.sh confirms: "ABI
surface changed; ABI_SEMVER bumped 0.5.0 -> 0.6.0. OK".

0.6.0 is unreleased, so the id-keyed surface is redefined in place rather than
bumped again — ABI_VERSIONING.md sanctions that pre-1.0. A load-time hard fail
is also the right failure mode — loud, versus a plugin silently not serving a
runner. And absence is now structural: an empty runners means nothing is
registered, rather than a probe that could answer wrong.

The one real cost: a user pinned to an older heph-go-plugin.json finds that
plugin stops loading entirely after upgrading heph, not just its runners. The
release pipeline publishes matched manifests per version, so that is a
pinned-manifest scenario rather than the default path.

Three things that decided the wire format

stdio never crosses. StdioSpec::Fd owns a descriptor, and a runner has no
business reassigning the host's PTY slave. Only the fields a runner may change
round-trip; the host keeps the real stdio and re-applies it. Without that the
guest's defaults come back and silently replace a PTY slave with Null.

open is cancellable, the session's methods are not. DynExecRunner
composes StableCancel because a cold devenv evaluation is tens of seconds and
a Ctrl-C during it must reach the plugin. DynExecSession does not: prepare
is a fast pure transform on the spawn path and close is best-effort, so
there is nothing there worth cancelling.

base_env carries a known/unknown bit. None is not "empty": a container's
environment lives inside the container, and a caller asking where a PATH entry
came from must degrade explicitly rather than print a confident, wrong answer.

prepare becomes async

It may now cross the seam. This does not reopen the window #405 closed: the
only suspension point is before the fork, and fork-through-Handle stays one
synchronous run of proc_exec::spawn. The invariant is "nothing awaits between
fork and Handle", not "the function is not async" — the module docs asserted
the latter and are corrected here rather than left to mislead.

close joins teardown on ExecSession: a session inside a plugin can only be
closed by talking to it, while teardown must stay sync for the hard-abort
path, which exits without running destructors. There, a plugin-spawned process
is reaped by the host supervisor that tracked it. The SDK's close handler runs
close then teardown, in that order and for the same reason
ExecSessionPool::close_all does — the host's own teardown for a remote
session is None, so doing half of it would leak the shell until abort-reap.

Tests

7 in plugin-sdk, all crossing the real stabby vtable — a direct call would
prove nothing about the seam, and the seam is the point:

the spawn is rewritten to run the runner's client, real program demoted to an argument	PASS
the runner is reached on every spawn while the environment opens once	PASS
host-owned stdio survives the round trip	PASS
caps and max_concurrent cross	PASS
an unenumerable environment stays None, not empty	PASS
close is idempotent	PASS
a runner serves with no driver anywhere — the capability the break bought	PASS

The mux fixture is now the clearest statement of the shape: its socket path and
its per-spawn sequence number live on MuxSession, reached from prepare
because the host holds the object rather than a key it must hand back.

exec-runner 28, plugin-sdk 36, e2e/exec_runner_spec 4. lint clean,
abi-check clean.

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