v0.6.1

[0.6.1] - 2026-07-12: document the 0.6.0 traps

Patch release. Documentation only; no API or behavioral change. Everything here comes from migrating a real suite onto 0.6.0, where the two new features landed cleanly but three shapes in the surface misled a reader who was pattern-matching from the rest of the package.

Changed

• ContainsJson documentation now carries an explicit warning against folding a volatile value into the expected subset. ContainsJson asserts equality for every field placed in it: "subset" constrains which fields are checked, not how strictly they are compared. Pinning a duration reading, a server-generated identifier, or a legitimately-varying status therefore asserts more than the contract does, and the test fails on the first run that differs. This is the failure mode a migration onto 0.6.0 walks into, because collapsing a block of per-property checks feels mechanical enough to sweep a volatile field in with the stable ones, turning a presence check into an equality check.
• GetJsonValue<T> / GetJsonString / GetJsonElement are now documented as extending the receiver rather than the assertion chain, and as living in the JsonAssertions namespace, so they need using JsonAssertions;. Every other feature auto-imports through TUnit.Assertions.Extensions, which trains a reader to reach for Assert.That(response).GetJsonValueAsync<T>(...) first: that does not compile, and the resulting CS1061 never names the missing namespace. The namespace table, the entry-point list, and the cookbook pattern now all show the receiver form.
• HasJsonArrayLength and the other shape and value assertions now document that only the HttpResponseMessage forms take a CancellationToken (it flows to the body read; a string or JsonElement source has nothing to cancel). Passing one on a JsonElement reports CS1929 naming HttpResponseMessage as the required receiver, which points at the receiver when the fix is to drop the token.
• HasJsonTypeInfoFor<T> is now documented as the one assertion in the package that guards a failure class the rest of a suite can miss: a type absent from the JsonSerializerContext is not a compile error, and with a reflection fallback in the resolver chain a JIT test run serializes it happily while the published Native-AOT binary throws at runtime.
• MatchesProblemDetails now documents that it asserts the media type as well as the fields, so a separate content-type test becomes redundant on migration (which a strict analyzer set will flag as duplicate method bodies).