Database backups: timestamps are month-1/zero-indexed, are not zero padded, and duplicate backups are generated

### Describe the Bug

When I upgraded on Saturday, 2026-09-12, the backup file name is db_2026-8-12_20-35-56.sqite
```
# stat config/db/backups/db_2026-8-12_20-35-56.sqlite
File: config/db/backups/db_2026-8-12_20-35-56.sqlite
Size: 21716992 Blocks: 42416 IO Block: 4096 regular file
Device: 8,1 Inode: 529585 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2026-09-15 12:30:47.995058492 -0400
Modify: 2026-09-12 20:35:58.479893142 -0400
Change: 2026-09-12 20:35:58.479893142 -0400
Birth: 2026-09-12 20:35:56.983870134 -0400
```
Furthermore, there are two non-identical backups, despite upgrading once:
```
.rw-r--r-- 22M 12 Sep 20:35 db_2026-8-12_20-35-56.sqlite
.rw-r--r-- 22M 12 Sep 20:36 db_2026-8-12_20-36-2.sqlite
```
```
# diff db_2026-8-12_20-3*
Binary files db_2026-8-12_20-35-56.sqlite and db_2026-8-12_20-36-2.sqlite differ
```
```
# stat db_2026-8-12_20-36-2.sqlite
File: db_2026-8-12_20-36-2.sqlite
Size: 21716992 Blocks: 42416 IO Block: 4096 regular file
Device: 8,1 Inode: 529753 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2026-09-15 12:30:47.719054280 -0400
Modify: 2026-09-12 20:36:03.308967432 -0400
Change: 2026-09-12 20:36:03.308967432 -0400
Birth: 2026-09-12 20:36:02.985962465 -0400
```
Another user also confirmed this observation and that they have a
`db_2026-0-23_20-25-49.sqlite` created in January.

To the best of my knowledge, **no Gregorian-based civil dating system on the planet uses zero-indexed months** so this is inherently confusing, which is obviously absolutely _not_ what you want to deal with if you ever need to actually _use_ one of these backups. Further complicating this is: there are two backups for one upgrade, if I need to use one of these backups, **which one of them do I use?**

Also, I don't know how these timestamps are being generated (though the zero index hints at JS/Java, see below?), but the lack of zero-padding the digits is just anathema to me (e.g., look at my Grateful Dead concert recordings, bootlegs AND label releases). This is, however, less concerning since there shouldn't be a sorting issue that matters.

### Environment

- OS Type & Version: Ubuntu 24.04
- Pangolin Version: 1.20.x > 1.22.2, though it seems to go back much further than that.
- Edition (Community or Enterprise): ee

### To Reproduce

Upgrade Pangolin without backups disabled, review filenames of backups.

### AI Disclosure

Yeah, I checked with ChatGPT to see if somehow I just never ran across this as a convention before (despite actually being on the ISO-8601 Wikipedia page last week and my clear interest in timestamps given my contribution to this project).

### Expected Behavior

zero-padded, normal (i.e., 1-indexed) Gregorian month timestamps for file names in an ISO-8601 format, similar to that produced by GNU `date -Is`.

Start by reproducing an upgrade with backups enabled and inspect the generated files under config/db/backups/. Compare the filenames and contents of backups created during one upgrade. Done means backup names use zero-padded, 1-indexed ISO-8601-style timestamps and one unambiguous backup is generated per upgrade.

Written by the indexing model from the issue text.