fix(ts-sdk): forward apiSecret credentials

[realfishsam]

Summary

• Adds apiSecret to TypeScript ExchangeOptions and stores it on Exchange.
• Forwards apiSecret in sidecar credentials so Polymarket, Limitless, Probable, and GeminiTitan can receive the secret expected by core.
• Adds a focused regression test covering type acceptance and credentials forwarding.

Fixes #1371

Test Plan

• npm test -- --runTestsByPath tests/exchange-credentials.test.ts --runInBand
• npm test -- --runTestsByPath tests/sidecar-order-param-forwarding.test.ts tests/hosted-order-params-types.test.ts tests/exchange-credentials.test.ts --runInBand
• npx tsc --noEmit

Note: local TypeScript SDK tests/build needed an untracked minimal sdks/typescript/generated/src/index.ts stub because generated SDK artifacts are absent in this focused checkout; the stub was not staged or committed.

[realfishsam]

PR Review: PASS (NOT VERIFIED)

What This Does

This adds apiSecret to the TypeScript SDK ExchangeOptions, stores it on the base Exchange, and includes it in the credentials object sent to the sidecar. This matters for SDK consumers using HMAC/CLOB-style venue credentials where apiKey alone is insufficient.

Blast Radius

TypeScript SDK base client credential plumbing only: all TS SDK exchange subclasses inherit ExchangeOptions and getCredentials(), so any venue using apiSecret can now forward it to /api/{exchange}/{method} POST bodies. No core sidecar exchange logic, OpenAPI schema, Python SDK, or generated SDK artifacts are changed.

Consumer Verification

Before (base branch):
Static inspection of origin/main:sdks/typescript/pmxt/client.ts found no apiSecret?: string option, no this.apiSecret = options.apiSecret, and no apiSecret: this.apiSecret in the sidecar credential object:

apiSecret option: false
constructor assignment: false
credential forwarding: false

A TS SDK consumer could not express apiSecret via the typed base options, so sidecar calls could only receive apiKey, privateKey, funderAddress, and signatureType.

After (PR branch):
The PR adds all three required plumbing points:

export interface ExchangeOptions { apiSecret?: string; }
protected apiSecret?: string;
this.apiSecret = options.apiSecret;
...
return {
  apiKey: this.apiKey,
  apiSecret: this.apiSecret,
  privateKey: this.privateKey,
  funderAddress: this.proxyAddress,
  signatureType: this.signatureType,
};

The added test exposes getCredentials() through a subclass and asserts { apiKey, apiSecret, privateKey } are present. I could not complete a compiled TS SDK run because this checkout does not contain sdks/typescript/generated/src/index.js, and regenerating it is blocked by missing Java in the review environment.

Test Results

• Build: Core build PASS (npm --workspace=pmxt-core run build). TypeScript SDK build NOT VERIFIED: tsc fails before this change is exercised because ../generated/src/index.js is absent.
• Unit tests: NOT VERIFIED for TS SDK focused test for the same missing generated-client blocker. A root npm test run built core and ran 44 core suites successfully (795 passed, 3 skipped) before failing in the Python SDK phase because /usr/bin/python3: No module named pytest.
• Server starts: NOT VERIFIED (not needed for this base-class credential-plumbing change; local full verify did not reach a clean server smoke result because of environment/tooling blockers).
• E2E smoke: NOT VERIFIED (no generated TS client available locally).

Findings

No blocking findings.

PMXT Pipeline Check

• Field propagation (3-layer): N/A
• OpenAPI sync: N/A
• Financial precision: N/A
• Type safety: OK — the option, stored field, and ExchangeCredentials body all line up statically; the new unit test covers the base-class credentials object.
• Auth safety: OK — the secret is included only in the POST credentials payload; existing GET-read logic detects credentials via getCredentials() !== undefined, so calls with only apiSecret also avoid query-string GET dispatch.

Semver Impact

patch -- fixes missing TS SDK credential forwarding without changing existing public behavior.

Risk

Runtime verification through a compiled TypeScript SDK and actual sidecar request body remains unverified in this environment because generated TS artifacts are absent and OpenAPI generation requires Java, which is not installed here.