Avoid per-call malloc/free in predict()

[JackDanger]

Hi there! First time contributing!

I noticed that predict() does a malloc and free of dec_values on every call. For services that score one row at a time (which is most of how folks use the library, I imagine), that runs in a very tight loop, and on my setup it ends up costing more than the dot product itself for small models.

Quick local numbers (Apple M-series, clang -O3, median of 3 runs, predict() throughput):

                                                  before          after
heart_scale, binary, nr_class=2                  31.8  Mrows/s    32.1  Mrows/s    (≈ flat — system allocator is fast for 16B)
synthetic,   multiclass, nr_class=32              1.6  Mrows/s     4.3  Mrows/s    (≈2.7× — main win)
synthetic,   multiclass, nr_class=128 (heap)      1.2  Mrows/s     1.2  Mrows/s    (unchanged, as expected on the fallback)
synthetic,   binary, n=1000 features              0.30 Mrows/s     0.29 Mrows/s    (dot product dominates)

The biggest win is on small/medium multiclass. Binary on Apple Silicon barely moves because the system allocator's small-size fast path is already excellent — I'd expect glibc to look more like the multiclass row but I haven't measured it.

Happy to iterate if you want it different.

Disclosure: I used Claude Opus 4.7 to find and fix this performance problem.