docs(agent): the rust recipe's nextest and cargo2junit commands could never run

[mergify-ci-bot]

The Rust recipe got JUnit XML out of cargo-nextest with
cargo nextest run --message-format junit, and out of cargo test by piping
--nocapture output into cargo2junit. Neither works. Nextest has no JUnit
flag; its documentation enables the report through a [profile.<name>.junit]
block in .config/nextest.toml, written to
target/nextest/<profile>/junit.xml. cargo2junit converts cargo's JSON
output from stdin, needing -Z unstable-options --format json --report-time
and RUSTC_BOOTSTRAP=1 to unlock that on stable. Both recipes then handed the
upload step a junit.xml nothing had written. The cargo2junit
install was wrong too: taiki-e/install-action's tool list has no cargo2junit,
so the job failed before the tests. The page now carries the config form, the
JSON pipeline, a plain cargo install, and matching upload paths.

The NUnit console example was --result=junit.xml;format=junit. The runner's
documented --result formats are nunit3 and nunit2 only, and the unquoted
semicolon splits the command in most shells. It now uses the transform= form
NUnit documents, quoted, with the
nunit3-junit.xslt NUnit publishes.

Pest's "configure logging in your Pest.php" snippet called
TestSuite::getInstance()->log(...). TestSuite has no log method, so that
file would fatal on load.

The Vitest page documented VITEST_MERGIFY_DEBUG and MERGIFY_TEST_JOB_NAME.
Neither appears in the shipped reporter or its core dependency: the debug switch
is MERGIFY_CI_DEBUG, as the Playwright page already says, and there is no
job-name support. MSTest and NUnit now say where the JUnit logger puts its file,
since LogFilePath resolves against the test project's directory, not the
repository root.

Open question: nothing here executes these recipes. Every claim was checked
against each tool's published documentation or shipped package, but someone who
runs Rust, .NET or PHP CI should confirm them end to end.

[mergify]

Merge Protections

🔴 1 of 6 protections blocking · waiting on 👀 reviews

	Protection	Waiting on
🔴	🔎 Reviews	👀 reviews
🟢	🤖 Continuous Integration	—
🟢	👀 Review Requirements	—
🟢	Enforce conventional commit	—
🟢	📕 PR description	—
🟢	🚦 Auto-queue	—

🔴 🔎 Reviews

Waiting for

• #review-threads-unresolved = 0

This rule is failing.

• #review-threads-unresolved = 0
• #changes-requested-reviews-by = 0
• #review-requested = 0

---

Show 5 satisfied protections

🟢 🤖 Continuous Integration

• all of:
  • check-success = build
  • check-success = lint
  • check-success = test
  • any of:
    • check-success = test-broken-links
    • label = ignore-broken-links
  • any of:
    • -head-repo-full-name~=^Mergifyio/
    • check-success=Cloudflare Pages

🟢 👀 Review Requirements

• any of:
  • #approved-reviews-by >= 2
  • author = dependabot[bot]
  • author = renovate[bot]
  • all of:
    • -head ~= ^docs-agent/
    • author = mergify-ci-bot

🟢 Enforce conventional commit

Make sure that we follow https://www.conventionalcommits.org/en/v1.0.0/

• title ~= ^(fix|feat|internal|docs|style|refactor|perf|test|build|ci|chore|revert|ui)(?:\(.+\))?!?:

🟢 📕 PR description

• body ~= (?ms:.{48,})

🟢 🚦 Auto-queue

When all merge protections are satisfied, this pull request will be queued automatically.

[JulianMaurin]

this is now common to each framework, maybe we can make it a part to be sue on each tool page ?

[mergify-ci-bot]

🤖 I read this review and pushed a new revision.