fix: sync hyperliquid spec with upstream API changes

[realfishsam]

Fixes #547
Fixes #546
Fixes #529
Fixes #520

[realfishsam]

PR Review: VERIFIED

What This Does

Syncs Hyperliquid raw type definitions with upstream API changes: (1) adds users: string[] field to HyperliquidRawTrade, (2) adds optional builderFee?: string field to HyperliquidRawFill, (3) makes origSz optional on HyperliquidRawOpenOrder (only returned by frontendOpenOrders, not openOrders), and (4) adds a fallback in normalizeOpenOrder when origSz is undefined.

Blast Radius

• core/src/exchanges/hyperliquid/fetcher.ts -- type definitions only
• core/src/exchanges/hyperliquid/normalizer.ts -- normalizeOpenOrder() logic

No SDK changes, no OpenAPI changes, no other exchanges affected.

Findings

1. The origSz fallback (origSz ?? currentSz) is correct defensive coding. When origSz is absent, the order appears fully unfilled (filled = 0, remaining = currentSz). This is safe because the openOrders endpoint only returns active orders.
2. The users field on HyperliquidRawTrade is typed but never consumed by normalizeTrade(). The taker/maker addresses are available but not surfaced. This is acceptable -- it's a type-only sync.
3. The builderFee field on HyperliquidRawFill is also typed but not consumed by normalizeUserTrade(). Again, type-only.

No blocking findings.

PMXT Pipeline Check

• Field propagation: N/A -- new fields are on raw types only, not surfaced to unified types
• OpenAPI sync: N/A -- no BaseExchange changes
• Type safety: OK -- optional types are correctly handled with fallback

Semver Impact

patch -- internal type updates with backward-compatible runtime behavior

Risk

Minimal. The origSz fallback means that if a user fetches open orders via the openOrders endpoint (vs. frontendOpenOrders), the filled field will always show 0. This is a limitation worth documenting but not a bug.