fix(junitReporter): stamp suites with their real start time

[luantaraschi]

Motivation/Description of the PR

Resolves #5668.

junitReporter writes each <testsuite timestamp> from suite.startedAt (lib/plugin/junitReporter.js:135), but nothing ever set that field. Confirming @mirao's read: startedAt is assigned in exactly one place, lib/listener/steps.js:20, and only to individual tests. Mocha's Suite does not carry it. So toIso() always fell through to its new Date() fallback and every suite got stamped with the moment the XML was serialized, which is after that suite and its AfterSuite had already finished.

The steps listener now stamps the suite on event.suite.before, mirroring what it already does for tests two lines below.

One thing worth flagging: the existing junitReporter_test.js builds its fixtures with startedAt: Date.now() on each suite object, so the tests were exercising a field that production never produced. That is why the reporter's own suite passed while the output was wrong. I left those fixtures alone since they now describe reality, and put the new coverage on the listener instead.

Scope note: this covers the in-process run. Under run-workers, lib/mocha/test.js serializes a test's parent down to { title } and drops startedAt from the test payload as well, so a suite timestamp cannot cross that boundary without changing the worker payload. That looked like a separate change, so I left it out rather than widen this PR.

Type of change

• 🐛 Bug fix

Checklist:

• Tests have been added
• Documentation has been added (Run npm run docs) — N/A, no public API change
• Lint checking (Run npm run lint)
• Local tests are passed (Run npm test)

Two tests in test/unit/listener/steps_suite_started_at_test.js. They fail on the commit before this change with expected undefined to be a number, and pass with it.

Full unit suite on Windows: 758 passing / 13 failing before, 760 passing / 11 failing after. The 11 remaining failures are pre-existing path assertions that expect POSIX-style paths and see a C: drive letter (utils_test.js, utils/trace_test.js); they are identical with and without this change.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[luantaraschi]

The red appium job on this PR was not about the change, and it should be gone now. Recording what it was in case it comes up on other fork PRs.

The last CI here ran on 2026-08-07 and the Android job failed at the Sauce Labs handshake:

{"detail":"Authorization failed"}
WebDriverError: failed serving request POST /wd/hub/session: Unauthorized
Appium "before all" hook in "Appium"  Can't connect to WebDriver.

That is a missing credential, not a broken test. Fork pull requests do not receive SAUCE_USERNAME / SAUCE_ACCESS_KEY, and neither do Dependabot ones, so the job cannot pass from either. Grouping the last hundred Android runs by trigger shows the split cleanly: pushes to 4.x and pull requests whose head branch lives in the repo pass, while every Dependabot pull request in the same window fails at the same line.

You already fixed this on 2026-08-12 in 6a5ce8d3 / eb1bcdc5, "fix(ci): dont run appium tests for PRs from forked repos", which added the github.event.pull_request.head.repo.full_name == github.repository guard. This PR's run predated it by five days, which is the whole reason it looked red.

So I pressed Update branch to pick up the guard rather than leave a red X sitting on an approved PR. The Android job is skipped on the new head, as intended. The fresh runs are sitting at action_required, which is the fork-contributor gate, so they need an approval from a maintainer before they will report.