You need to round half-even to 3 decimal places.
The internal datetime is only stored to millisecond precision (in milliseconds since the julian epoch), so you will never no matter what you do get more accuracy than a millisecond. You cannot put back what is not there in the first place. Just as you cannot reconstruct quality video from compressed all to ratshit video no matter what the screaming media companies (or others) tell you.
Secondly, you are running on Windows x64. From your results I would guess that you are also using a Microsoft compiler on x64. How do I know? Microsoft compilers cannot do floating point arithmetic. Either (a) switch to 32-bit which can do arithmetic properly or (b) switch to a different compiler.
How do I divine this magical information? Simple. I am running on Windows 10 x64 and and using the Mingw64 GCC compiler, and it gets "more better" answers to the same questions (floating point arithmetic is performed to within .5 ULP) -- it is a trade-off though because while MSVC cannot do floating point arithmetic properly, it gets correct answers for its mathematical functions (ln/log/exp/sin/cos etc) -- MinGW64 GCC the situation is reversed in that it can do arithmetic correctly but cannot compute a math function (ln/log/exp/sin/cos).
```
SQLite version 3.34.0 2020-11-05 19:31:02
Enter ".help" for usage hints.
Connected to a transient in-memory database.
Use ".open FILENAME" to reopen on a persistent database.
sqlite> create table t(s text, f real);
sqlite> insert into t(s) values ('2016-06-13T09:36:34Z');
sqlite> insert into t(s) values ('2016-06-13T09:36:34.123Z');
sqlite> insert into t(s) values ('2016-06-13T09:36:34.123456Z');
sqlite> update t set f = (julianday(s) - 2440587.5) * 86400.0;
sqlite> select * from t;
┌─────────────────────────────┬──────────────────┐
│ s │ f │
├─────────────────────────────┼──────────────────┤
│ 2016-06-13T09:36:34Z │ 1465810594.00001 │
│ 2016-06-13T09:36:34.123Z │ 1465810594.123 │
│ 2016-06-13T09:36:34.123456Z │ 1465810594.123 │
└─────────────────────────────┴──────────────────┘
sqlite> select s, printf('%.6f', f) from t;
┌─────────────────────────────┬───────────────────┐
│ s │ printf('%.6f', f) │
├─────────────────────────────┼───────────────────┤
│ 2016-06-13T09:36:34Z │ 1465810594.000009 │
│ 2016-06-13T09:36:34.123Z │ 1465810594.123001 │
│ 2016-06-13T09:36:34.123456Z │ 1465810594.123001 │
└─────────────────────────────┴───────────────────┘
sqlite> .version
SQLite 3.34.0 2020-11-05 19:31:02 91cd3839204a000f79887243fbbb1678f185b14e479b5b6781b057e7ec5cec7c
zlib version 1.2.11
gcc-9.1.0
sqlite>
```
Secondly, do not forget that any access to the clock (or wait states, sleeps, dispatcher preemption/scheduling, etc) has a granularity of just shy of a 16 ms "system tick" by default unless you have changed the frequency of the system timer.