feat(plugin-devenv): ship devenv as a cdylib plugin, not a builtin

[raphaelvigee]

On top of the generic-runner PR. devenv is a real cdylib plugin now, not a
builtin.

It was asked for as a loadable plugin during design and shipped as a builtin:
crates/plugin-devenv had no [lib] crate-type, and bootstrap.rs registered
both halves unconditionally into the host binary. My miss.

What changed

crates/plugin-devenv-cdylib — crate-type = ["cdylib"], loaded from a
heph-devenv-plugin.json manifest, exactly like go/gha/oci. The host binary no
longer links plugin-devenv at all.

Two components, both named devenv: a driver that builds the environment
artifact, and an exec runner (#418) that serves sessions from it. Separate
components, because a runner is not a driver — it has no schema, parses nothing,
builds nothing.

Being the runner is what makes this plugin the party that decides how the
process starts: ExecSession::prepare is per target, so one devenv shell is
opened once inside the plugin and every target's exec is routed into it.

Since #418 hands the host a live session object rather than an id, that shell —
its socket, its pid — simply lives on the session. Runner is a single field
again: the Mutex<HashMap<String, Arc<dyn ExecSession>>> and the AtomicU64
that minted ids existed only to answer the host by a name it had invented, and
both are deleted here.

SessionSupport moves into the plugin, where it belongs: current_exe() in a
cdylib is the host binary, which is exactly the agent and per-target client a
session needs, and home/root come from CreateConfig. The host no longer
assembles it.

Packaging

Ships as a release artifact on all three targets, same flow as the others:

• one more package in the single cargo build — splitting it would serialize a
  fourth LTO tail
• staged into dist/, macos-portable.sh'd, version-slot patched, manifest
  generated by tools/pluginmanifest, published
• pattern: "heph*" and files: dist/* pick it up with no further change
• install-devenv-plugin for local use; gen-example runs it, since
  example/exec_runner/BUILD uses driver = "devenv"
• qualityCrates gains the crate — a new crate missing there lints green
  locally and red in CI, which has already cost time once on this stack

Tests

Two in bin-e2e, which is the only place this seam exists — an in-process test
constructs the driver through generics and never crosses it:

the shipped cdylib dlopens and its devenv driver answers across the ABI	PASS
devenv no longer resolves with no plugin configured	PASS

The second is the one that matters. Without it the conversion half-lands: the
builtin keeps answering, every fixture passes, and nobody notices the cdylib is
dead weight that is never loaded.

Verified against real staged release artifacts — plugin_dylib 12/12.
exec-runner 37, plugin-devenv 10, engine 545, heph 128, e2e/exec_runner 12.
lint clean.

Note for reviewers

e2e is a devenv script and is baked at shell start, so an existing shell
still stages the old three-artifact list and this suite fails on a missing
heph-devenv-plugin.dylib. Re-enter the shell (or direnv reload) before
running e2e locally. CI is unaffected — it starts a fresh shell.

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