TL;DR: It may be that I resolved the issue. It was about too short timers. When setting it to 3600/1800 all started working normally.
Here's more for those who want to know the details.
I thought maybe the Win2019 server is not really meant for SLAAC but rather for DHCPv6 or static configuration. I went to the office to test it with two laptops, Windows 10 and Linux Mint. But before that I also checked the lifetimes in my home network behind a smaller Fortigate. There I saw that both a Windows 10 desktop computer and a Linux Mint laptop got 30 minutes preferred and valid lifetimes and these were renewed in time so it never went under 20 minutes and therefore never timed out as well. Besides, I haven't experienced any IPv6 disconnects at home ever since I got it working about a year ago. I think I didn't touch the valid/preferred lifetimes in my home Fortigate but this I need to check later.
In the office behind the big Fortigate things seemed worse. I used wifi for testing. A Windows 10 laptop took the same 3600/120 lifetimes from the Fortigate and when the 120 seconds was over it lost IPv6 connectivity just like the Win2019 server did. But that caused the Windows to start a diagnostic because I saw how the Wifi was shortly disabled and enabled automatically and after that it connected to another wifi network that was preferred (and without IPv6). When I reconnected, it didn't get the SLAAC address, or if it did then after waiting for about 5 or 10 minutes.
The Linux behaved much better in the same WLAN in the same time as I tested with Windows 10 laptop. Initially, it didn't get the SLAAC address at all (why?) but eventually it did. Checking with "ip a" I saw that it also got the preferred and valid timers as specified in the IPv6 config in Fortigate. After the preferred lifetime ticked down to 0 ("ip a" showed it) the valid lifetime was periodically renewed without the preferred time being renewed; still, the preferred lifetime was also renewed periodically, just less often. But I never lost the IPv6 connectivity with this Linux Mint laptop with 3600/120. The valid lifetime never went lower than about 3100 seconds and the IPv6only.me showed my address even when the preferred lifetime was 0 for a while.
So there is dependency on the operating systems how they handle/renew the SLAAC timers given to them.
Then I got an idea: what if the Windows 10 considers 120 seconds as a lifetime which was meant by the network administrator to get rid of the address? That is, it's too short? And in this case it is just the problem with my testing timers only. Because at home it was 30 minutes and with no problems. Also there are some RFC's about it, like this, a good one about timers and considerations regarding networking changes with IPv6:
https://datatracker.ietf.org/doc/html/rfc8978 They propose valid/preferred lifetimes of 90 minutes / 45 minutes.
I changed the valid/preferred timers to 3600/1800, that is, 1h/30m. And there you go: now the preferred lifetime never went under 20 minutes on the Linux Mint laptop and two different Windows 10 laptops that I used to test the IPv6 connection, so it was renewed in time. The Linux Mint also renewed the timer now so it didn't go to 0 anymore, that is, this OS also considers 120 seconds too short but instead of losing connectivity, it survived the disconnect. Win2019 testing server also renews it's preferred lifetime in time. It looks like 20 or 21 minutes is the shortest lifetime to use for setting a preferred lifetime. And also it means that most possibly the long default values work well except when considering cases presented in rfc8978.