dayjs.utc('....') parases milliseconds incorrectly

**Describe the bug**
When parsing a timestamp using `utc()` the Milliseconds part is interpreted incorrectly.
The timestamp is from a postgresql database. pgsql datatype is "timestamp without time zone".

```
let d = dayjs.utc("2022-10-01T11:34:02.02");
d.format("SSS"); // output is "002", correct would be "020"
d.toISOString(); // output is "2022-10-01T11:34:02.002Z"

d = dayjs.utc("2022-10-01T11:34:02.2");
d.format("SSS"); // output is "002", correct would be "200"
d.toISOString(); // output is "2022-10-01T11:34:02.002Z"

d = dayjs.utc("2022-10-01T11:34:02.020");
d.format("SSS"); // output is "020" (this is correct)
d.toISOString(); // output is "2022-10-01T11:34:02.020Z" (correct)

// If you append a "Z" to the timestamp millis are parsed correctly.
d = dayjs.utc("2022-10-01T11:34:02.02Z");
d.format("SSS"); // output is "020" (this is correct)
d.toISOString(); // output is "2022-10-01T11:34:02.020Z" (correct)
```

**Expected behavior**
".02" miliseconds should be interpreted as "20" milliseconds and not as "2"
".2" miliseconds should be interpreted as "200" milliseconds and not as "2"

**Information**
- Day.js Version: tested on the day.js website in dev tools
- OS: windows 10
- Browser Firefox 117.0.1
- Time zone: GMT+2

Start by reproducing the reported utc() examples with fractional seconds, checking format("SSS") and toISOString() for each input. The issue names no source file or test path; done means .02 produces 020 milliseconds, .2 produces 200, and existing three-digit and Z-suffixed inputs remain correct.

Written by the indexing model from the issue text.