fix(cli): support compiled next cli e2e runtime

[jgoux]

Summary

• Run the next CLI e2e suite against the compiled dist/supabase-next binary so tests exercise the same artifact users run.
• Fix the two compiled-Bun blockers tracked by CLI-1452 and CLI-1453.

CLI-1452: functions dev and native/runtime assets

The compiled next binary could not boot commands that pulled in @parcel/watcher, because the native optional package is not embedded by bun --compile and the fallback .node path does not exist inside Bun's embedded filesystem.

This PR keeps the compiled binary path viable by making the next CLI e2e harness run through dist/supabase-next, and by embedding the Edge Runtime bootstrap with Bun's native text import attribute instead of resolving the bootstrap through a runtime source-file path. The Edge Runtime service writes that embedded bootstrap source into the runtime temp directory before launching the function runtime.

CLI-1453: compiled binary daemon/supervisor dispatch

Compiled Bun ignores the script-path argv shape that works in JIT mode, so child_process.fork(daemonEntryPoint) re-entered the compiled CLI entrypoint instead of running the daemon script.

This PR makes compiled-binary dispatch explicit: forkDaemon marks daemon children through the environment, and the compiled next CLI entrypoint routes that child process directly to the daemon runner. The same pattern is used for process supervision: @supabase/process-compose forks through process.execPath, uses a tiny env protocol only for compiled-Bun self-dispatch, and otherwise remains a generic Node/Bun process supervision library. The supervisor runtime/protocol are native .ts files, so Bun forks Bun and Node forks Node.

Reviewer Notes

The process-compose changes are intentionally runtime-neutral: there are no Supabase-specific paths or command names in the library. Supabase-specific compiled-binary dispatch lives in the CLI/stack entrypoints that own that behavior.