I used 'dmesg -w' via SSH to monitor dmesg output as the syste=
m froze. I have
not seen anything of interest, and no new messages were printed before the
crash took place. The only arguably suspicious line was:

[ 1286.800069] perf: interrupt took too long (2502 > 2500), lowering
kernel.perf_event_max_sample_rate to 79750

Never the less, I have discovered another important factor during my tests:=
 I
decided to look through my BIOS settings again, as I remembered I had left
enabled a memory overclock setting called Performance Enhance. In the past =
when
I had a different set of memories, this option caused the exact same freeze
when I was watching Youtube (1080p @ 60fps videos). Later on I got new
memories, and due to how my clocks are synced I'm running those at an
underclocked (therefore more stable) frequency, so I figured I can leave th=
is
enabled without problems. The highly erratic probabilities of the freezes t=
hrew
me off (once it's after 10 minutes, then it's after 2 hours), whereas a cra=
sh
this obvious would have been all over the bug tracker by now if it was Mesa.

After disabling it, I no longer seem to get any immediate system freezes. It
will however require more testing to confirm it was that option, so please =
give
me a few more weeks before we close this. If my theory is proven wrong, I'll
immediately post a new comment and let everyone know.