feat(interpreter): real background execution with & and wait

[chaliy]

Summary

Background execution (&) is currently parsed but runs synchronously. This is the single biggest capability gap — unlocking real async & would enable parallel downloads, concurrent test runs, and producer/consumer patterns.

Current State

• cmd & is parsed and accepted
• But the command runs synchronously (blocks until complete)
• wait exists but has nothing to wait for
• $! returns a virtual PID
• jobs, bg, fg are intentionally excluded (no job control)

Proposed Behavior

Feature	Description
cmd &	Run command asynchronously via tokio::spawn
wait	Wait for all background jobs to finish
wait $pid	Wait for specific background job
wait -n	Wait for any one background job to complete
$!	Real (virtual) PID of last background command
PIPESTATUS	Updated correctly after wait

Use Cases

# Parallel downloads
curl -o file1.txt https://example.com/1 &
curl -o file2.txt https://example.com/2 &
curl -o file3.txt https://example.com/3 &
wait
echo "All downloads complete"

# Background processing with result check
long_computation > result.txt &
pid=$!
# ... do other work ...
wait $pid
status=$?
if [ $status -eq 0 ]; then echo "Success"; fi

# Fan-out/fan-in
for file in *.csv; do
    process "$file" > "${file%.csv}.json" &
done
wait

# Wait for first completion
cmd1 & cmd2 & cmd3 &
wait -n
echo "First one finished with $?"

Implementation Notes

• Use tokio::spawn to run commands concurrently within the interpreter
• Each background job gets its own cloned interpreter state (like a subshell)
• Background jobs share the VFS (Arc) — this is safe since VFS is already thread-safe
• Need a job table to track spawned tasks and their JoinHandles
• wait collects results from the job table
• Resource limits should be shared across background jobs (total commands, total output)
• Security: background jobs must not escape sandbox — same restrictions as foreground
• This does NOT require OS-level process spawning — it's cooperative async within the interpreter
• jobs/bg/fg/signals remain excluded (no terminal job control)