native: float64 arrays bound by name or saved on a record are stored as float32; to_json_list epoch millis 1 ms off #175

Two values the native build (arcadedb) returns differently from what was written, while arcadedb-jvm returns them as written. Found by a value round-trip probe that writes and reads the same values on both builds (22,042 cells per build on the 26.11.1.dev0 dev wheels).

• float64 arrays stored as float32. A float64 numpy array bound by name (... v = :v with a dict), inside CONTENT :row, or set on a record object and saved, goes through the float32 side buffer, so [0.1, 0.2, 0.3] reads back as [0.10000000149011612, ...] on native and as [0.1, 0.2, 0.3] on JVM. Cause: src/arcadedb/_native/codec.py _default sends every float ndarray through the side buffer in binary mode, and the non-binary F tag builds a float[] too. insert_many already keeps the doubles on both builds. A float array as a lone positional ? is a query vector and goes as float32 on both builds, as documented; that rule stays.
• to_json_list epoch milliseconds 1 ms off. Native computes epoch milliseconds as int(total_seconds() * 1000) (codec.py json_native), so 1969-12-31 23:59:59.999999 gives 0 instead of -1, and 9999-12-31 23:59:59.999999 rolls into year 10000; the JVM build floors like Instant.toEpochMilli.

Fix: only float32 arrays take the side buffer (other float arrays keep their doubles on every path except the documented positional query vector), and epoch milliseconds use integer arithmetic that floors. Shared tests for both, including float32 guards and the positional rule.