Report which backend startup stage failed without exposing private logs #5107

User Story

I run OpenShell with a registered isolation backend. If startup fails before the workload runs, I need sandbox status to identify the failed stage and failure category without requiring access to privileged supervisor logs.

Related work: Attach-refusal reporting #4739, implemented by PR #4791. This issue builds on that behavior with short, safe diagnostics for Build, Attach and Confirm.

Problem Statement

With the Attach-refusal behavior from PR #4791 applied, failures while constructing the backend (Build) or confirming startup (Confirm) still need useful public status.

Reporting every startup failure as a policy refusal would hide whether the cause was an actual Attach denial, invalid configuration or an infrastructure problem. Reports also need authentication and checks that they belong to the current sandbox instance, launch generation and approved configuration.

Impact / Why This Matters

A generic supervisor exit or misleading policy refusal gives users little help choosing the next step. Copying raw backend errors into public status could expose privileged information.

OpenShell needs a short, stable failure category for the correct startup attempt while preserving the original error if reporting itself fails.

Acceptance Criteria

• Build, Attach and Confirm failures produce stable, bounded stage and failure-kind status.
• Only an actual denied Attach is classified as a policy refusal.
• Reports are authenticated and fenced to the current instance, generation and complete admitted configuration.
• The original startup error is preserved even if bounded reporting fails.
• Stale or mismatched reports cannot overwrite status for another instance, generation or admitted configuration.
• Failure reporting never changes a failed startup into a Ready sandbox.

Reproduction Steps

1. Use an OpenShell deployment with a registered isolation backend and the Attach-refusal reporting behavior from PR #4791.
2. Start a sandbox whose backend fails during construction; repeat with a backend confirmation failure after configuration admission.
3. Inspect sandbox status through OpenShell. Compare the reported failure category with the failing startup stage.
4. Compare with an actual denied Attach: construction and confirmation failures must not be reported as policy refusals.

Suggested UX (if applicable)

Sandbox status should identify a stable startup stage (Build, Attach or Confirm) and failure kind. An Attach policy denial should remain distinct from configuration and infrastructure failures; public status should not contain raw privileged backend text.

Environment

• OpenShell source assessed: 42671c2dd2c02b744850e0bda72b99d5509969c1.
• Integration: registered isolation backend using shared supervisor startup and gateway status reporting.
• Prerequisite: the Attach-refusal behavior in PR #4791.

Logs