This is probably mime type support based on eith the name of the file or something something that reads a file and guesses its type. It might be that the file is oddly named.
I don't suppose you could supply a direct link to the svg image that is not properly being typed? It isn't obvious when I look at the sample page.

I have updated the linked pages to uses SVG again. It should be an image at the top of the page, but instead there is alt text phase diagram.

Direct link is here:
https://docs.pagure.org/fork/lsedlar/pungi/_images/phases.svg

Please note that displaying the image in Firefox directly by visiting the above URL works despite the wrong Content-Type, but once it is included in a page it stops showing up.

Yeah the content-type is bad either way, it's just that the browser does something it shouldn't, to try to help broken web sites that just makes things confusing.
You don't need to leave it broken any more as long is the svg file stays so I can test it directly. The web page can get back whatevr fix you put in. I was confused by the fix since an image was showing up, but wasn't an svg.
In theory I should be able to figure out why this happens and propose a fix.

If the pagure.io site uses httpd, then this appears to be controlled by /etc/mime.types unlesss there is some override set in the httpd configuration.
So my best guess right now is that this is a site configuration bug rather than a bug in the Pagure source.
I am not sure how to confirm that though.

I have found in at least some places pagure does try to figure out mime types, but I'm not sure if it applies in this case.

The documentation for the mimetypes python module suggest you are supposed to call mimetypes.init, but I am not seeing that. That should be testable by me, but I don't have a local pagure instance configured yet. This module does draw off the local mime.types file, so there still be a lack of configuration for .svg files on the web server.

I did a short test of a python script using mimetypes and found that init isn't needed and a number of sources for mime types were listed including /etc/mime.types. If /etc/mime.types had an svg entry the correct type was returned, if not it, wasn't and something later probably defaulted to html.
So I am thinking this is very likely a server configuration issue and someone with access, will need to double check it.

FTR this is what's on the server:

$ grep 'svg' /etc/mime.types 
application/vnd.oipf.dae.svg+xml
image/svg+xml                   svg svgz

mime.types looks OK. It could be that Pagure is relying on the web server to do the type guessing and the web server config is wrong, but it may be that this file is being handled by different code. I'll need to have a working instance of Pagure to test. I have been slowly working toward that for other reasons, but don't have it setup yet. Thanks for confirming the server settings.

Also reported in https://pagure.io/pagure/issue/2143

Also reported in #2532

Fixed in https://pagure.io/pagure/pull-request/2778