jq.Evaluate rounds non-integer numbers to 2 decimals (0.001 becomes 0.00)

hi - i opened #255 with a fix for this, but @babakks asked to file an issue first so we have a thread to discuss. so here it is.

`jq.Evaluate` rounds non-integer numbers to 2 decimal places, so the output loses precision. the worst case is `0.001`, it prints as `0.00` - a nonzero value ends up as zero.

repro with input `{"pi": 3.14159, "small": 0.001, "big": 123456.789}`, evaluating `.pi`, `.small`, `.big`:

```
.pi => 3.14
.small => 0.00
.big => 123456.79
```

real jq keeps full precision there (3.14159, 0.001, 123456.789).

the cause is `jsonScalarToString` in `pkg/jq/jq.go` - the non-integer branch does `strconv.FormatFloat(tt, 'f', 2, 64)`, hardcoded to 2 decimals. the doc comment says scalars are written "similar to how jq --raw works", and jq itself doesnt round, so to me it reads like a bug and not intended behaviour.

the direction i took in #255 is precision `-1` (the shortest string that round-trips the float64) for the non-integer branch, and leaving the integer branch as is so whole numbers dont grow a trailing `.0`. but im happy to go a different way if you'd prefer to handle it some other way. just wanted somewhere to discuss it. thanks!

Start in pkg/jq/jq.go at jsonScalarToString and reproduce the provided .pi, .small, and .big inputs. Compare the non-integer output with jq's full-precision values, then verify that whole-number output remains unchanged and the sample values no longer lose precision.

Written by the indexing model from the issue text.