The site is an exercise for me in getting things out sooner than later, because I tend to struggle with perfectionism quite a lot [*]. After my 111 days of daily writing I'll probably port it back to https://sonnet.io / 11ty where I have more control over the UX.
Thanks for a really interesting post!
Normal browser scrolling logic has a mechanism to avoid such conflicts; if you have some sub-element that's scrollable, a continuous scroll motion that started over the page body will continue scrolling the page body, even if a scrollable sub-element passes under the cursor. If you move the mouse over a sub-element and then try to scroll, then it'll scroll the sub-element.
Whatever this page is doing is breaking that logic.
They told you what it's doing. There is a webgl window that your cursor is hitting and the input is going to that. It should be pretty clear, you can see the 3D window view start changing.
Click on the embed, focus border appears, now scrolling with the mouse within the window scales the rendering. Scrolling outside or clicking away from the embed returns the scrolling behavior to normal. This is one of those things that breaks the simple model of "lazy composability."
"Whatever this page is doing" was with regards to the implementation details of the elements in question, not the actual reason why the issue was happening.
The author of the page considered it a bug as well: https://news.ycombinator.com/item?id=38598921
(I don't think "click before scrolling" is necessarily the right UI fix here, though. Ideally it'd be browser-style "if scrolling starts on the UI element it scrolls that element, but not if it just passes over that element during a scroll of the page".)