Expose structured execution outcomes and configurable framework exit codes

[autocarl]

Context

Consumer feedback attached to #79 exposed a broader exit-contract gap than process-signal handling alone. Today:

• routing refusal, binding failure, and an unhandled handler failure can collapse to the same exit code;
• ReplNext returns only ValueTask, and ReplExecutionContext does not expose the handler result;
• command middleware runs after some routing decisions and before the process-signal exit policy, so it cannot observe or transform every final outcome;
• translating the final integer at the entry point is lossy because an explicit handler code can be indistinguishable from a framework-selected code.

PR #80 deliberately keeps conventional signal codes focused and does not introduce a general result-policy API.

Desired design

Expose a structured final execution outcome and a backwards-compatible policy/interception point capable of distinguishing at least:

• successful execution;
• help/no-op invocation;
• route or argument refusal;
• binding/validation failure;
• explicit handler result;
• unhandled handler exception;
• caller-requested cancellation;
• process SIGINT, Ctrl+Break, or SIGTERM cancellation.

The API should let an application map framework outcomes to its published exit-code contract without rewriting every handler. It should define precedence when both a signal and an explicit non-zero handler result exist.

Acceptance criteria

• Routing refusal can use a code distinct from handler failure.
• A consumer can map or intercept the final structured outcome once, after all framework layers have run.
• Explicit handler exit codes remain identifiable rather than being inferred from an integer.
• Existing middleware and Run/RunAsync behavior remains source- and binary-compatible, or migration is documented.
• Tests cover routing, handler failure, explicit results, caller cancellation, and process-signal outcomes.
• Documentation includes a recommended contract for headless child processes.