`FailureMode.Continue` masks failure: target reports Done and the process exits 0

[BrewingCoder]

FailureMode.Continue does what its name suggests for plan sequencing: after a
plan fails, the remaining plans in the target still run. That part is useful and
is exactly what I needed.

The problem is what it does to the outcome. Verified with a deliberately
three-plan probe, where the middle plan is guaranteed to fail:

Target PlanFailureProbe => _ => _
    .FailureMode(FailureMode.Continue)
    .Executes(() => new[]
    {
        DotNetTool.Plan("--version"),
        DotNetTool.Plan("nonexistent-subcommand-xyz"),   // fails
        DotNetTool.Plan("--info"),
    });

Observed:

• plan 1 runs
• plan 2 fails, and Tamp logs ==> PlanFailureProbe FAILED (exit 1)
• plan 3 still runs (good, this is the point of the mode)
• Build Summary reports PlanFailureProbe ✓ Done
• the Tamp process exits 0

So Tamp knows the plan failed and says so mid-log, then discards that fact in
both the summary and the exit code.

For a test-running target this is a live footgun: a suite with failing tests
produces a green build and a zero exit status. In CI that is indistinguishable
from a pass. I had to add a separate downstream target with
AssuredAfterFailure() that re-reads the TRX result files and throws, purely to
put the failure back.

Suggested fix, any of:

1. Keep running the remaining plans but still mark the target failed and exit
   non-zero. That seems like the intuitive reading of "continue".
2. Add a distinct mode (ContinueThenFail, or a FailureMode.Continue
   parameter) so the swallow-the-failure behaviour is opt-in rather than implied.
3. At minimum, document the exit-code behaviour prominently, since the current
   name reads as "keep going", not "keep going and forget it went wrong".

[BrewingCoder]

Fix plan (option 1 — matches the enum's own contract)

FailureMode.Continue is documented as "Target failure is logged but does not stop the build." The bug is that the implementation additionally marks the target Done and exits 0, which contradicts that contract and turns a failed suite into a green CI run.

Root cause: Continue conflates three things in Executor.RunActual — (a) within-target plan sequencing (run remaining plans after one fails), (b) target outcome, (c) build outcome. (a) is the useful part; (b)/(c) are wrong.

Fix:

• Keep (a): after a plan fails under Continue, the remaining plans in the target still run.
• Keep the non-aborting build behavior: subsequent targets still run (that's what "does not stop the build" means — distinct from Fatal).
• Correct the outcome: the target is recorded Failed (not Done), and the process exits non-zero. Same for an exception thrown under Continue (currently swallowed as success).
• buildFailedAt (the abort trigger) stays unset for Continue, so it doesn't mark later targets NotRun; a separate non-aborting failure tracker drives the exit code. Failure handlers (OnFailureOf) remain undispatched for Continue (unchanged).

Net: Continue == "run everything, don't abort, but still fail the build." The #23 compact FAILED (N): summary + the ✗ row now reflect it.

Behavior change (intended): a Continue target that fails now exits non-zero. This is the footgun fix; anyone who relied on the swallow can drop the target or gate it with OnlyWhen.

Implementing now.