chore(deps): update tunit to 1.43.41

[thomhurst]

This PR contains the following updates:

Package	Type	Update	Change
TUnit	nuget	patch	1.43.38 → 1.43.41
TUnit.AspNetCore	nuget	patch	1.43.38 → 1.43.41
TUnit.Assertions	nuget	patch	1.43.38 → 1.43.41
TUnit.Core	nuget	patch	1.43.38 → 1.43.41
TUnit.Engine	nuget	patch	1.43.38 → 1.43.41

---

Release Notes

thomhurst/TUnit (TUnit)

v1.43.41: 1.43.41

What's Changed

Other Changes

• feat(playwright): expose default Context/Launch options on settings by @​thomhurst in #​5861
• fix(hooks): resolve TestDiscovery hook context type by attribute kind, not method name by @​thomhurst in #​5860

Dependencies

• chore(deps): update tunit to 1.43.38 by @​thomhurst in #​5858

Full Changelog: v1.43.38...v1.43.41

---

Configuration

📅 Schedule: (UTC)

• Branch creation
  • At any time (no schedule defined)
• Automerge
  • At any time (no schedule defined)

🚦 Automerge: Enabled.

♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about these updates again.

---

• If you want to rebase/retry this PR, check this box

---

This PR has been generated by Mend Renovate.

[claude]

Code Review

This is a straightforward Renovate bot PR bumping 5 TUnit NuGet packages from 1.43.38 → 1.43.41 in Directory.Packages.props. The change is minimal and mechanical — only version strings are modified.

One observation worth a quick check:

TUnit.Assertions.FSharp remains pinned at 1.43.38 (line 103 in the diff context) while all other TUnit packages advance to 1.43.41. If TUnit.Assertions.FSharp is published in lockstep with the rest of the TUnit suite, this mismatch could cause a NuGet resolution conflict or silent API incompatibility. It would be worth verifying:

• Is TUnit.Assertions.FSharp intentionally excluded from this update (e.g., it lives in a separate repo/release track)?
• Or should it also be bumped to 1.43.41?

If the version skew is intentional (different release cadence), a brief comment in Directory.Packages.props grouping it separately from the other TUnit packages would prevent future confusion.

Everything else looks correct. The change is consistent across all 5 packages, auto-merge is set, and CI gates should catch any compatibility issues before merge.

[codacy-production]

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

🟢 Metrics 0 complexity

Metric	Results
Complexity	0

View in Codacy

_{NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.}