fix: broaden postOrder/postOrders return types to include ClobErrorResponseBody

[osr21]

Problem

Since v1.1.0 postOrder() and postOrders() return Promise<OrderResponse> / Promise<OrderResponse[]>. But when throwOnError is false (the default), a failed submission resolves to { error: string; status: number } (a ClobErrorResponseBody) at runtime.

TypeScript consumers get no compile-time warning. Accessing .orderID on an error object throws at runtime.

Fix

Change the return types:

• postOrder → Promise<OrderResponse | ClobErrorResponseBody>
• postOrders → Promise<(OrderResponse | ClobErrorResponseBody)[]>

ClobErrorResponseBody is already imported in client.ts. A JSDoc comment on each method documents the union.

Migration

// Before (silently wrong at runtime):
const result = await clob.postOrder(order);
console.log(result.orderID); // 💥 if order was rejected

// After (type-safe):
const result = await clob.postOrder(order);
if ("error" in result) {
  console.error("Order rejected:", result.error, result.status);
} else {
  console.log("Order placed:", result.orderID);
}

Fixes #91

---

Note

Low Risk
Type-signature and documentation only; no runtime logic change, though TypeScript callers may need explicit error narrowing.

Overview
Broadens TypeScript return types so they match runtime behavior when throwOnError is false (the default): failed submissions can resolve to a ClobErrorResponseBody instead of always looking like a successful OrderResponse.

createAndPostOrder now returns Promise<OrderResponse | ClobErrorResponseBody>, and postOrders returns Promise<(OrderResponse | ClobErrorResponseBody)[]>. Each method gets JSDoc noting that rejected/failed orders may appear as error bodies rather than thrown exceptions.

Consumers should narrow results (e.g. check for "error" in result) before reading fields like orderID.

^{Reviewed by Cursor Bugbot for commit 6b7dc09. Bugbot is set up for automated code reviews on this repo. Configure here.}