`miden` wrapper collapses every component exit code to 1

[omerbek]

What happens

When midenup is invoked through the miden multicall wrapper, it forwards the command to the active toolchain component and gets the child process ExitStatus back from Config::execute_command().

If that child exits with any non-zero status, the wrapper currently turns it into an anyhow error:

if status.success() {
    Ok(())
} else {
    bail!("'{}' failed with status {}", user_input, status.code().unwrap_or(1))
}

Because src/main.rs returns anyhow::Result<()>, every child failure is then collapsed to process exit code 1.

Why this matters

The miden wrapper behaves like a transparent command dispatcher, so callers generally expect the wrapped component's exit status to survive. Today CI scripts cannot distinguish, for example, a component usage error, a component-specific failure code, or a Rust panic exit (101): they all become 1 at the wrapper boundary.

This also adds a second wrapper error line after the child command already reported its own failure.

Expected behavior

For miden <component-or-alias> ..., the wrapper should return the child process exit code when the child exits normally with a non-zero code.

For signal termination on Unix, a conventional 128 + signal mapping would preserve more information than 1; on non-Unix platforms, status.code().unwrap_or(1) is still a reasonable fallback.

Code path

miden <command>
  -> Behavior::Miden(argv)
  -> miden_wrapper::miden_wrapper(...)
  -> Config::execute_command(...) -> ExitStatus
  -> bail!(...) on non-zero
  -> main() -> anyhow::Result<()> termination
  -> process exits 1

The related open PR #229 touches command execution environment construction, but this is a separate wrapper exit-status propagation issue.