Failed or inconsistent config-preflight commands can report worker capacity

Summary

The worker-status parser can report delegation/capacity from a config_preflight.py command whose execution metadata contradicts the helper result, because preflightStatus() validates the command text and JSON payload but does not reconcile the command's explicit status/exit code with that payload.

Reproduction / evidence

Current upstream main at 37bf87a692fc72d41f7312cc48808d699d204fba routes completed command events through preflightStatus() whenever the command matches config_preflight.py and aggregated_output contains a recognized capability document.

A deterministic contradictory event is:

{
  type: "item.completed",
  item: {
    type: "command_execution",
    command: "python3 /plugin/scripts/config_preflight.py --profile security_scan",
    status: "failed",
    exit_code: 2,
    aggregated_output: JSON.stringify({
      profile: "security_scan",
      status: "ready",
      results: [
        { capability: "delegated_workers", status: "pass" },
        { capability: "usable_worker_slots_6", status: "pass", actual: 8 },
      ],
    }),
  },
}

Current behavior: workerStatusFromEvent() reports delegation available with configuredSlots: 8.

Expected behavior: explicitly failed or internally inconsistent command metadata must not be presented as trustworthy capability evidence.

Important exit-code semantics

config_preflight.py intentionally uses nonzero exit codes for valid evaluated states:

• ready -> 0
• blocked -> 1
• incomplete -> 2
• helper/parser error -> 2 with an error envelope

So a blanket exit_code !== 0 rejection would be wrong: valid blocked/incomplete results can still contain useful delegation/capacity observations.

Root cause

preflightStatus() checks the outer event and payload shapes independently but never reconciles them.

Suggested fix

• always reject item.status === "failed";
• when a numeric exit_code is present and the payload has a recognized top-level status, require the documented status/exit mapping;
• for legacy payloads that omit a top-level status, retain exit 0 compatibility but reject unexplained nonzero exits;
• preserve valid blocked and incomplete capability observations.

Add focused regressions for explicit command failure, contradictory status/exit combinations, and valid ready/blocked/incomplete controls.

Impact

This is observability correctness. The CLI/dashboard can otherwise display worker delegation and configured capacity from execution metadata that says the helper did not produce that successful result.

Start by locating preflightStatus() and its callers in workerStatusFromEvent(), then reproduce the contradictory item.completed event described in the issue. Add focused regressions for explicit command failure, contradictory status/exit combinations, and valid ready, blocked, and incomplete results. Done means failed or unexplained metadata cannot produce trusted capacity, while valid nonzero evaluated states remain usable.