fix(symbolConverter): return 0 szDecimals for outcome markets

[pucedoteth]

What & why

SymbolConverter.getSzDecimals returns 5 for every outcome market, but outcome shares trade in whole units, so it should be 0.

Evidence:

• The Hyperliquid app hardcodes it. Its bundle (app.hyperliquid.xyz/assets/index-*.js) builds outcome rows with szDecimals:0,coinKind:"outcome".
• Live mainnet data has no fractional sizes. I checked 2,466 recentTrades across 304 outcome coins, then 332 open outcome orders and 267 non-zero outcome balances from 96 of the traders. Every size was an integer.

Since getSzDecimals feeds both formatters, 5 breaks orders built the way docs/guides/market-orders.md shows:

formatSize("12.5", 5);             // "12.5"   (fractional share size)
formatPrice("0.29128", 5);         // "0.2"
formatPrice("0.29128", 5, "spot"); // "0.291"

formatSize("12.5", 0);             // "12"
formatPrice("0.29128", 0);         // "0.29128"

0.29128 is a real resting bid on #32530. With 5, an IOC buy priced off it gets cut to 0.2 and doesn't fill.

The change is the constant in _processOutcomeMarkets, plus the JSDoc example, docs/utilities.md and the outcome getSzDecimals() test.

Type of change

• Bug fix
• New API method / feature
• Schema/type update to match the Hyperliquid API
• Breaking change

Testing

• deno test -A tests/utils/symbolConverter.test.ts: 2 passed (27 steps). With only src/utils/_symbolConverter.ts reverted, the outcome getSzDecimals() step fails (5 vs 0).
• deno task check passes (fmt, lint, type check, jsdoc sync, export sync).
• I did not send a fractional-size outcome order to the exchange, so the rejection itself is inferred from the app and the live data above.

Written with AI assistance (Claude Code).

🤖 Generated with Claude Code