Avoid float64 for precision-sensitive fields in Go SDK (precision loss)

[Shaahkral]

Summary
In the Go implementation, many precision-sensitive fields (prices, sizes, rates, increments, etc.) are modeled as float64. Using IEEE-754 binary floats for decimal financial data leads to non-exact representations and downstream rounding mismatches. Please avoid float64 for these fields and keep them as strings (or a decimal/string wrapper type) to preserve exactness.

Why this matters
Most decimal values (e.g., 0.1, 123.45678901) are not exactly representable as float64.

Clients often need lossless 8-dp (or more) values for storage, signatures, parity checks, tick math, and deterministic re-serialization.

Converting to float64 early forces every consumer to implement bespoke quantization/rounding logic and still risks off-by-one ticks when scaling.

Examples of affected areas
market.GetFullOrderBookResp (bid/ask price & size)
market.GetSymbolResp (price/size, limits)
futurespublic.InstrumentEvent (prices, funding)
(Non-exhaustive; the general request is to avoid float64 for all monetary/decimal fields.)

Observed behavior
SDK unmarshals JSON into float64. Re-emitting, comparing, or scaling (e.g., value*1e8) can yield non-deterministic/rounded results versus the original wire value.

Expected behavior
Keep monetary/decimal fields as strings in the public DTOs to preserve the exact lexeme from the wire.

Request
Please replace float64 monetary/decimal fields with strings (or a DecimalString wrapper) across the Go SDK DTOs to guarantee lossless precision and deterministic behavior.