fix(hooks): emit hook.failed when a helper suite hook throws

[luantaraschi]

Motivation/Description of the PR

Resolves #5660.

@mirao's trace is correct and I followed it through the code. event.hook.failed is only emitted by fireHook(), which is only reached from the injected() wrapper used for test-file-defined BeforeSuite() / AfterSuite(). A custom helper's _beforeSuite() / _afterSuite() takes a different route:

lib/mocha/ui.js:106 registers suite.beforeAll('codeceptjs.beforeSuite', suiteSetup(suite)) → suiteSetup emits event.suite.before → lib/listener/helpers.js:30 queues runAsyncHelpersHook('_beforeSuite', ...) on the recorder. When that throws, it surfaces in suiteSetup's recorder.errHandler, which called doneFn(err) and nothing else. No hook.failed, so junitReporter's listener never fired and the report stayed empty.

Both error handlers now emit the matching hook object before calling done. I passed the mocha suite straight through, which is what fireHook() already does, so hook.ctx.test and hook.hookName come out the same shape junitReporter already consumes (['BeforeSuite', 'AfterSuite'].includes(hook.hookName)).

I did not reuse fireHook() here: it derives the hook kind from suite.ctx?.test?.title?.match(/"([^"]*)"/)[1], and these hooks are titled codeceptjs.beforeSuite, which has no quoted segment, so that match returns null and the indexing throws.

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 appended to test/unit/mocha/asyncWrapper_test.js, one per hook. They queue a throwing helper method the same way runAsyncHelpersHook does and assert both that done still receives the error and that hook.failed carries the right hookName. Both fail on the commit before this change with hook.failed was emitted.

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

Related: #5683 fixes the other half of the junit reporting gap @mirao reported, the suite timestamp.

[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.