unit-tests target reports AggregateException despite passing direct tests

## Environment
- Consumer repository: agenda
- Pipelines package: Candoumbe.Pipelines 2.0.0
- .NET SDK: 10.0.201
- OS: Linux (dev container)
- Test runner context: Microsoft.Testing.Platform enabled in global.json and tests.props

## What I expected
Running the unit-tests target should provide a deterministic unit-test signal:
- fail only when unit tests fail, or
- fail with a clear, isolated reason directly tied to test orchestration.

## What happened
Running:
`./build.sh unit-tests`

fails in Nuke summary with:
- UnitTests failed
- AggregateException
- Process dotnet exited with code 2
- downstream test-related targets not run

At the same time:
- running `./build.sh unit-tests --skip Format` can succeed
- direct unit test execution succeeds (validated examples):
- Agenda.API.UnitTests: 44/44 passed
- Agenda.Objects.UnitTests: 21/21 passed

Additionally, the same unit-tests invocation traverses non-unit-test concerns (Format, BuildFrontend), which can introduce unrelated blockers (package vulnerability audit messages, frontend budget warnings), making diagnosis difficult.

## Repro steps
1. Use a consumer project with:
- Candoumbe.Pipelines 2.0.0
- .NET SDK 10.0.201
- Microsoft.Testing.Platform enabled
2. Run:
`./build.sh unit-tests`
3. Observe Nuke summary failure on UnitTests with AggregateException and dotnet exit code 2.
4. Compare with:
`./build.sh unit-tests --skip Format`
5. Compare with direct test runs:
`dotnet test tests/Agenda.API.UnitTests/Agenda.API.UnitTests.csproj`
`dotnet test tests/Agenda.Objects.UnitTests/Agenda.Objects.UnitTests.csproj`

## Short log snippet
```
Target UnitTests has thrown an exception
AggregateException: One or more errors occurred.
Process dotnet exited with code 2.
Nuke summary: UnitTests failed; downstream targets not run.
```

## Impact
- Hard to distinguish true unit test failures from orchestration/precondition failures.
- Slower CI and local triage.
- Reduced confidence in the unit-tests target as a test-only quality gate.

## Suspected root cause
Possible orchestration coupling in the unit-tests flow:
- non-unit-test stages are part of the same execution path
- when one of those stages or command wiring fails, the top-level signal appears as a generic UnitTests AggregateException, obscuring root cause.

## Proposed improvements
1. Provide a strict unit-tests mode that excludes unrelated concerns (format/frontend/audit) by default.
2. Improve error reporting to clearly attribute failure to the exact sub-step and command.
3. Distinguish in summary:
- test assertion failures
- prerequisite/pipeline failures
- process invocation failures
4. Document recommended behavior with .NET 10 and Microsoft.Testing.Platform enabled.

## Optional workaround
- Use:
`./build.sh unit-tests --skip Format`
- Validate unit test health independently with direct dotnet test commands while diagnosing orchestration issues.

Could you please confirm whether this behavior is expected in Candoumbe.Pipelines 2.0.0, and what target strategy you recommend for a strict, deterministic unit-test gate?

Start with build.sh and the UnitTests target, then inspect global.json and tests.props for Microsoft.Testing.Platform settings. Reproduce ./build.sh unit-tests and compare it with --skip Format and the listed direct dotnet test commands. Done means the target reports the exact failing sub-step and provides a deterministic unit-test-only gate without unrelated Format or BuildFrontend blockers.

Written by the indexing model from the issue text.