fix: Parallelize integration test suite (338s -> 77s)

[MQ37]

What

Fixes notifications/progress delivery (a real MCP-spec-compliance bug: _meta was placed at the notification's top level instead of inside params, so any strict client silently dropped the message) and uses it to give integration tests a deterministic way to learn a run's runId. Uses that to remove the last blocker to running tests/integration/suite.ts concurrently instead of sequentially.

Why

The integration suite forced concurrent: false for two reasons: every test shared one client variable/afterEach(close) (races under concurrency), and 3 abort/cancel tests discovered the Apify runId via a run-list-polling heuristic that isn't safe if another test touches the same Actor at the same time. Fixing notifications/progress (see first commit) replaces that heuristic with a direct signal from the server, removing the need for isolation. Also deleted 2 tests whose "top of a desc: true, limit: N listing" assertion only held under the old sequential ordering — real concurrent Actor runs from other tests can push their target off page 1; unit coverage for both tools already exists separately.

Testing

pnpm run type-check, lint, format, check:agents, test:unit (1137 passed) all clean. Full integration suite against the real Apify API, both transports, before vs after:

• before (sequential, original code): 338.45s, 240 passed / 19 skipped / 0 failed
• after (concurrent, this PR): 77.24s, 236 passed / 19 skipped / 0 failed (the 4 fewer = the 2 deleted tests × 2 transports)

Independently re-verified via a fresh subagent (re-ran the full suite against the live API itself, not just the reported numbers).

[vojtechj-apify]

Clients leak on test failure now that cleanup moved into the test body.

The old afterEach(() => client?.close()) ran even when a test failed. The new pattern puts await client.close() as the last statement of each test body, so any earlier expect failure or thrown error skips it:

client = await createClientFn();
const prompts = await client.listPrompts();
expect(prompts.prompts.length).toBe(0);  // if this throws…
await client.close();                     // …never runs → leaked client

A leaked client is a child process (stdio) or a server session (streamable-http). Several tests carry { retry: 1..3 }, and with concurrent: true a flaky test now leaks a client per attempt, in parallel — exactly the resource pressure concurrency adds, which can cascade into more flakiness.

Suggest guaranteeing cleanup with try { … } finally { await client?.close() }, or a test.extend fixture with automatic teardown (also removes the repeated let client / await client.close() boilerplate). I know onTestFinished was tried and raced on a shared module-level variable — a try/finally or fixture sidesteps that since neither relies on vitest's current-test tracking.

---

Generated by Claude Code