fix: re-enable stress-test seeding assertions and allow manual dispatch

[supertokens-agent-runner]

Problem / root cause

The 1M-user stress-test suite (stress-tests/) is meant to make query-path
durations trustworthy and comparable across runs, but two gaps undermine that:

1. Silently-swallowed seeding errors. In
   stress-tests/src/oneMillionUsers/createUsers.ts the four user-creation
   steps had their result assertions commented out
   (// expect(createdUser.status).toBe("OK")) and only kept a user on
   status === 'OK', dropping any non-OK result on the floor. A seeding step
   that partially errored still let the run finish green, which invalidates
   every measurement taken downstream of the smaller-than-expected dataset.
   (There is no expect/jest in this plain ts-node harness, so the literal
   commented line could never have run as-is.)
2. No manual trigger. .github/workflows/stress-tests.yml only exposed a
   workflow_call interface, so the suite could only run as part of a release
   workflow — it couldn't be run on demand against a published dev image.

Fix approach

• Added a small FailureTracker singleton to stress-tests/src/common/utils.ts
  (mirroring the existing StatsCollector). Each of the five creation steps now
  records a non-OK result against its step name instead of silently dropping it,
  and throwIfAnyFailures() prints a per-step summary and throws at the end
  of the run. Counting-and-failing-at-the-end (rather than aborting on the first
  non-OK) is deliberate: seeding and the read steps still complete and
  stats.json is still written, but the overall run fails so untrustworthy
  numbers aren't mistaken for a clean baseline.
• Added a workflow_dispatch trigger to stress-tests.yml with the same
  required tag string input the workflow_call interface takes. The existing
  ${{ inputs.tag }} reference in the compose-image step is populated for both
  trigger types, so no other workflow change was needed.

Scope note (other step files): the issue asked to check the other seeding
step files for the same pattern. I audited all of them
(accountLinking.ts, addRoles.ts, createSessions.ts,
createUserIdMappings.ts, importMillionUsers.ts) — the commented-out
assertion pattern exists only in createUsers.ts. The other steps call
void-returning recipe methods that throw on hard failure; wiring status
assertions into them would require deciding which non-OK statuses are
acceptable during random linking/mapping and risks spurious run failures, so I
left them unchanged to honor the issue's "no behavior changes otherwise". They
are candidates for the measured-step work in the follow-up unit.

No behavior change to shipped core or to any SDK — this touches only the
stress-test harness and its CI workflow.

Tests / verification run locally

This is a test-harness change; the full suite seeds 1M users against a live
core and is not runnable in the iteration window. What I ran locally in
stress-tests/:

• npx tsc --noEmit — passes (type-checks the changed TS).
• npx prettier --check on the three changed .ts files — all match style.
• Exercised FailureTracker directly via ts-node: empty tracker →
  throwIfAnyFailures() is a no-op and logs the all-clear line; after
  recording non-OK results it aggregates per step (e.g.
  EmailPassword users creation: 2 non-OK result(s) — {"EMAIL_ALREADY_EXISTS_ERROR":2})
  and throws with a count summary.
• Validated stress-tests.yml parses and now exposes both workflow_call and
  workflow_dispatch with the tag input.

Not verified

• A full end-to-end suite run (1M-user seed + read steps) — needs the release
  dev image and a long-running core; CI / a manual workflow_dispatch run is
  the place to confirm the wired end-of-run failure path against real data.

Cross-SDK note

N/A for porting: this is CI/test-harness code that lives only in
supertokens-core; it has no counterpart in the supertokens-node / -python /
-golang repos and makes no semantic change to core behavior.

Part of PLAN-006.

Fixes #1335