fix(workspace): fail closed and report execution state for trusted workspace tests #2612

Goal

Make basectl workspace test fail closed and unambiguous when any selected project lacks manifest-command trust.

Background

A current workspace run reported FAIL project 'base' followed by the manifest trust error, then continued executing the trusted base-bash-libs test. The per-project basectl test gate correctly refused base, but the workspace orchestrator treated that refusal as an ordinary project failure and continued by default. Because delegated output is buffered and stderr is rendered after the outer result, the user cannot tell which test actually ran or whether the blocked test ran.

This creates a dangerous and misleading execution boundary for a workspace command.

Scope

• Preflight manifest-command trust for every selected test target before starting any delegated test.
• If any selected target is trust-blocked, execute zero project test commands and report the workspace as blocked.
• Distinguish blocked, not_run, failed, passed, and skipped states in text and machine-readable output.
• Show explicit preflight, start, completion, command, and elapsed-time information in text mode; state clearly when a command was not executed.
• Add workspace test dry-run/plan output that shows resolved commands and trust decisions without execution.
• Preserve ordinary runtime-failure continuation and --fail-fast semantics after trust preflight succeeds.

Acceptance Criteria

• If any selected project is untrusted, no selected project test command is launched, including projects that are trusted.
• A blocked project is never rendered as a generic test command exited with status 1 result.
• Text output explicitly reports EXECUTION BLOCKED, 0/N tests started, and the affected project/command.
• Successful execution reports each project start and completion, including the resolved command and duration.
• JSON reports preflight outcome, execution-started state, trust status, and per-project blocked/not-run results without breaking the published contract; update the schema/version deliberately if required.
• Direct basectl test trust errors explicitly say that no project test command was executed.
• Regression tests prove that a blocked first and blocked later target both prevent all workspace test launches; ordinary runtime failures retain documented continuation/fail-fast behavior.

Validation

Run focused workspace Python tests, manifest-command-trust BATS tests, workspace JSON schema/contract tests, relevant integration tests, and the supported Base test gate. Include a real-launcher temporary-workspace regression with one blocked project and one trusted project, proving the trusted command is not launched.

Non-Goals

• Do not weaken or auto-grant manifest-command trust.
• Do not change direct basectl test trust policy.
• Do not change the independent-project selection contract covered by Keep selected workspace tests independent of unselected broken projects #2224.

Project Fields

• Status: Ready
• Priority: P1
• Area: Workspace
• Initiative: Contract Hardening
• Size: M
• Assignee: codeforester
• Category: bug

Agent Assignment

Agent-ready. Implement the bounded workspace execution-boundary correction, update the public output/schema contract, and provide focused evidence.