fix(testing)!: refuse a scenario no layer can reject

[sephynox]

Summary

A tb_scenario! whose configuration named no effective verifier ran green regardless of what the code did, and thirteen assertion contracts were satisfied by every possible count. Both are now refused rather than reported as passes.

Related Issues

None

Changes Made

• ScenarioConfigBuilder::build returns Result
• A config no layer can reject is refused, not run
• An expectation no layer can produce is refused
• at_least!(0) no longer compiles
• Four scenarios that graded nothing now grade real events

Testing

• make test-all: passes

Breaking Changes

• ScenarioConfigBuilder::build now returns Result<ScenarioConfig, ScenarioConfigError>.
  • Callers using tb_scenario! need no change.
  • A caller that builds a config by hand adds ? or .expect(..)
  • A helper returning ScenarioConfig changes its return type to match.
• Cardinality::new and Cardinality::at_least(u32) are gone -- at_least now takes NonZeroU32.

---

Note

Medium Risk
Breaking ScenarioConfigBuilder::build API and stricter compile-time spec rules affect all tb_scenario! and hand-built test configs; behavior is confined to the testing framework, not runtime services.

Overview
Scenarios with no real verifier can no longer pass by default. ScenarioConfigBuilder::build() returns Result and refuses configs where no assertion/CSP/FDR layer can reject a run, or where Expect::Violation names a layer that cannot produce that violation. tb_scenario! unwraps via __tb_accept_config! (panic with the refusal reason); manual builders must use ? or .expect(...).

Assertion cardinality no longer allows no-op contracts. at_least!(0) fails at compile time; optional labels are omitted from the spec instead. TBSpec::can_reject() treats empty assertion lists (mode-only specs) as non-verifiers unless gate decisions, required events, or schedulability constraints apply.

Tests and fuzz targets drop vacuous at_least!(0) entries and give formerly empty tb_assert_spec! blocks real exactly! assertions so they still build under the effective-verifier rule.

^{Reviewed by Cursor Bugbot for commit 613cbfd. Bugbot is set up for automated code reviews on this repo. Configure here.}