4.0: configuration traits and warning severity (W1)

[DanielCech]

Stacked on #22. Step 2 of the 4.0.0 plan.

Why

In the JustFlip proof of concept, 26 call sites passed the same timeout: because screens with seeded data need longer than the 2 s default. And teams adopting dealloc tests in an existing project need a way to see leaks without failing CI on day one.

What's new

@Suite(.deallocationTimeout(.seconds(5)))
struct ScreenDeallocTests { … }

@Suite(.deallocationIssues(.warning))   // leaks are reported, the test passes
struct LegacyDeallocTests { … }

• DeallocationConfiguration (timeout, severity) is a task-local default that every check uses unless it passes its own value.

• Precedence: an explicit argument wins over a test's trait, and a test's trait wins over its suite's.

• XCTest has no traits, so withDeallocationConfiguration({ $0.timeout = .seconds(5) }) { … } does the same. It runs on the caller's actor, so it works from @MainActor tests; the first version didn't, and the new tests caught that.

• Warning severity:

  • Swift Testing 6.3+: an issue with severity: .warning;
  • Swift Testing 6.1/6.2: an intermittent known issue;
  • XCTest: a non-strict expected failure.

  Each issue still goes to exactly one framework, which matters under Swift 6.4's XCTest/Swift Testing interop.

• timeout parameters (expectDeallocation, trackForDeallocation, .checksDeallocation, the DI helper) are now Duration? with a nil default. This is source compatible.

Tests

• Swift Testing: a suite timeout applies, a test trait wins over the suite, an explicit timeout wins over traits, withDeallocationConfiguration works, warning severity doesn't fail the test, .checksDeallocation uses the configured timeout.
• XCTest: withDeallocationConfiguration changes the timeout; warning severity doesn't fail the test.
• macOS (both trait configurations) and the iOS simulator pass.

🤖 Generated with Claude Code