docs(test-filters): add migration callout for --filter → --treenode-filter

[johnkattenhorn]

Small docs-only change. Adds a tip callout to the top of the existing test filters page so users coming from xUnit / NUnit / MSTest find the --filter → --treenode-filter mapping before they go looking for it.

Why

VSTest's dotnet test --filter "Category=X" is familiar to anyone migrating. On Microsoft.Testing.Platform the flag is silently rejected, the MTP help is printed, and the run exits with Zero tests ran. It looks like a test failure when it's actually just an unrecognised flag — I hit this myself running an AI dev agent against a TUnit project (the agent spent ~11 minutes trying filter variations before giving up). Easy signposting seemed like the lightest-weight fix.

Scope

Single file: docs/docs/execution/test-filters.md. One callout block plus a three-row mapping table, links back into the existing filter examples that already cover the destination syntax comprehensively. Nothing else touched.

Alternatives considered

• Adding to each of the three migration pages (xunit.md, nunit.md, mstest.md). They currently focus on code syntax rather than CLI, so one central callout felt lighter than three duplicate ones.
• A brand-new "Running tests from xUnit/NUnit" page. Felt like overkill for a small signpost.

Love TUnit — using it heavily on a new project. Thanks for building it.

[codacy-production]

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

_{TIP This summary will be updated as you push new changes. Give us feedback}

[johnkattenhorn]

One alternative we considered but deliberately kept out of this PR: teaching the test runner to detect --filter and emit a "Did you mean --treenode-filter?" hint on the way out, instead of just printing the full help. That would give immediate feedback to both humans and AI agents — the 11-minute discovery loop I described in the PR would never start in the first place.

Not included here because it's a bigger surface (likely Microsoft.Testing.Platform-level CLI parsing rather than TUnit itself) and docs felt like the right first step. Flagging it in case it's worth an upstream conversation.

[thomhurst]

Thanks!