What JorgeV is correctly saying is that the page itself is of little importance, what matters is the code that your server returns for the HTTP requests that results in a 404 page.
Open developer tools section of your browser, specifically the network tab (this shows you the errors and responses), then enter the url that returns the 404 page. The first entry in the list should be the request for the page in question, and it should return a 404 status code. If it returns a 200 status-code then would have found your problem.
Note, since you posted a link to your site (which is against WW policy) I checked and the page returns 404. But I also noted that requests to any other non-existent url redirects to this one url. My guess is that this is the problem. If a url does not exist and never has existed it should return 404. It is fine if a page once existed and you redirect it to an existing page, but it makes no sense to redirect a page to a page that then returns a 404. My guess is that GSC may also be showing you many soft-404 errors.
The comment from @NickMNS makes me think that, if the page existed, in the past, then Google might still has the old page indexed. It might not yet have tried to visit the page, so it might not yet be aware of the 404.
Also, if the page existed, it's better to send a 410 code (page gone), like that SE know the page no longer exists on purpose, and it was not temporarily accident.
A tiny glitch in coding can result in the 404 page being requested in its own right, by name. It works like this:
request for nonexistent page, using wrong protocol and/or hostname >> server generates 404 response >> internal request for 404 page >> external redirect to 404 page, by name, with correct protocol and hostname
(As usual, 95 guesses how I know. Oops.) Solution: Make sure your 404 page is exempt from any and all redirects. For added insurance, attach a noindex meta to all your error documents, so even if a search engine gets there by mistake, it won't show up in searches.