bvisor: support self-hosted launcher dispatch for single-binary applications

[heyoub]

Problem

The Linux safety design correctly requires a fresh single-threaded launcher process. Today that launcher is only a separate bvisor-linux-launcher package binary.

A single-binary application depending on bvisor cannot include dependency binaries through Cargo, so cargo install <application> and a single release artifact cannot provide confinement without separately installing and locating the launcher. Copying launcher internals downstream would fork the security-critical implementation.

The desired shape is still two processes, not an unsafe in-process launch: the application executable re-execs itself into an early, single-threaded bvisor launcher mode.

Requested neutral contract

Expose a public Linux launcher dispatcher/entrypoint behind backend-linux:

• an application calls it at the first line of main, before logging, runtimes, or threads;
• it positively identifies a bvisor launcher invocation from authenticated/frozen launcher wire state and otherwise returns NotLauncherInvocation;
• on a launcher invocation it never returns, running the same coordinator implementation as the package binary;
• LinuxBackend can be configured with the current executable plus the supported self-hosted dispatch marker;
• no command-line-only marker is trusted as launcher authority;
• the separate bvisor-linux-launcher binary becomes a thin caller of the same public implementation, not a second copy.

Proof requested

• one application binary successfully confines a workload through re-exec;
• ordinary application startup cannot be confused with launcher mode;
• user-supplied argv/env without the inherited authenticated descriptor topology is refused;
• dispatcher called after threads/startup state fails closed or is structurally impossible;
• identical plan/report bytes between dedicated and self-hosted launcher modes;
• no ambient fd/env widening;
• cross-platform builds return a typed unsupported result without pulling Linux implementation.

Downstream containment

The downstream will keep launcher selection inside one compatibility module. Until this ships, it can require the dedicated launcher explicitly; afterward the adapter becomes an early dispatch plus current_exe configuration, preserving the one-binary install story.

[heyoub]

Disposition (BatPak clean-room 5.5E1): Superseded with full mapping — deferred by DEC-023. V1 executes no arbitrary native/Wasm guests. This issue's lesson (authenticated launcher descriptor topology; argv/env are never launcher authority) is now a typed DEC-023 reopening prerequisite (spec/dispositions.rs, docs/30): the capability cannot reopen without satisfying it. Not forgotten, not implemented.