feat: js-sdk emitter — align generated suites to the real @camunda8/orchestration-cluster-api SDK (follow-up to #348)

Summary

The js-sdk emitter introduced in #348 (intended to close #131) renders real
request bodies and requestPlan steps, but it is written against a
@camunda8/sdk API surface that does not match the real published SDK
(@camunda8/orchestration-cluster-api, the package built by
camunda/orchestration-cluster-api-js — see issue #131's title). As a result
the emitted suite would not compile/run against the real package: it is the
same class of executable-correctness gap as the Python emitter (#354), just
less obvious because the JS emitter does lower real request bodies.

This follow-up tracks aligning the JS emitter to the real SDK so
codegen:js-sdk:all produces runnable suites.

Mismatches (verified against camunda/orchestration-cluster-api-js README + its examples/operation-map.json)

All in materializer/src/js-sdk/emitter.ts (and materialize-support.ts):

• Package + factory name. Emitter imports createApiClient / ApiClient /
  RestClientError from @camunda8/sdk (emitter.ts:~94-95,
  materialize-support.ts:~36/51/181/187). The real package is
  @camunda8/orchestration-cluster-api; the factory is createCamundaClient
  (default + named export). There is no ApiClient type (use
  ReturnType<typeof createCamundaClient>) and no RestClientError export.
• Success has no HTTP wrapper. Emitter asserts expect(response.status).toBe(200)
  (emitter.ts:~259) and extracts via response.data<accessor> (~264). The
  real SDK methods return the deserialized body directly — there is no
  .status or .data on success. Status assertions and data extraction must be
  reworked to operate on the returned body.
• Error shape. Emitter does error as RestClientError then reads .status
  (emitter.ts:~250). The SDK throws plain Error objects that carry .status
  and are detectable via isSdkError(e); there is no RestClientError type to
  cast to.
• Op-map shape mismatch (dead weight). OperationMapJsonSource.fromJson
  (sdk-mapping.ts:~14/28) expects Record<string,string>, but the real
  examples/operation-map.json is Record<string, {file,region,label}[]>.
  lookup() therefore always returns undefined and the emitter falls back to
  toCamelCase(opId). That fallback is coincidentally correct (method name ==
  operationId in camelCase), so calls resolve — but the op-map plumbing is
  effectively unused and should either be removed or re-typed to the real shape.

Definition of done

• codegen:js-sdk:all emits suites that compile and run against
  @camunda8/orchestration-cluster-api (factory createCamundaClient,
  body-direct returns, isSdkError-based error handling).
• response.status / response.data assumptions removed; status/extract logic
  operates on the returned body.
• Op-map source either removed or re-typed to the real array-of-objects shape
  (no silent always-undefined fallback masquerading as a lookup).
• tests/codegen/js-sdk-emitter.test.ts updated to assert the real SDK call
  shape; JS L3 invariants in configs/camunda-oca/regression-invariants.test.ts
  assert real emitted content (not just file presence).

Context

• Original feature issue: #131.
• Sibling follow-up for Python: #354 (same class of gap).
• C# emitter (materializer/src/csharp-sdk/emitter.ts) is the closest
  executable reference in-repo.
• Review thread: https://github.com/camunda/api-test-generator/pull/348
  (comment on js-sdk/emitter.ts re: aligning to the real package).