Add subprocess guest

[delbonis]

Description

This draft, speculative PR adds a new "process" guest type that runs the proof program as a subprocess, as an alternative to the native runner to allow for more fine-grained control over tracing and more holistic error/panic handling.

Type of Change

• Bug fix (non-breaking change which fixes an issue)
• New feature/Enhancement (non-breaking change which adds functionality or enhances an existing one)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation update
• Refactor
• New or updated tests
• Dependency Update

Notes to Reviewers

Checklist

• I have performed a self-review of my code.
• I have commented my code where necessary.
• I have updated the documentation if needed.
• My changes do not introduce new warnings.
• I have added tests that prove my changes are effective or that my feature works.
• New and existing tests pass with my changes.

Related Issues

[prajwolrg]

This is an interesting direction — the "guest as a subprocess" framing gives us real failure isolation and a clean per-run boundary for tracing, and the structured error protocol (exit codes + CBOR ErrorOutput) is a nice way to make guest failures machine-readable instead of catastrophic.

That said, I'm trying to pin down the concrete value over the native runner and wanted to write up where I land:

• Panics in testing/fuzzing we can already handle in-process with catch_unwind, so isolation alone doesn't buy us much there.
• OOM and timeouts are the failure modes that actually bite us, but in our case those happen in the riscv simulation (the SP1/Risc0 execution), not in the native run. Since the process runner executes the same program logic as native, wrapping it in a subprocess doesn't isolate the part that actually OOMs/hangs. So I'm not sure this addresses the limitation we hit in practice.

@evgenyzdanovich you've worked most closely with this kind of thing — curious for your take here. This also is related with alpenlabs/alpen#1933.