Why do you want to serve those static assets with a
gz extension at all?
Despite being the common indicator for ages, file extensions are actually an inferior and inaccurate mechanism to communicate a MIME type in the first place: ideally, web resources should be entirely agnostic to file extensions and only communicate their content by means of appropriate HTTP headers like
Content-Encoding (which by the way eases maintaining an URI space as well - Cool URIs don't change ;)
Granted, this has not worked in the early days of the internet, and might still not work with a few inferior clients (annoyingly some proxies and weaker mobiles seem to suffer from this still), but unless you can clearly identify a relevant portion of your audience being affected from this limitation (and nudging them to upgrade their browser eventually is not an option), you should probably start to simply trust the HTTP headers in use instead.
Consequently I'd simply serve the static assets pre-compressed with the
Content-Encoding and (to address your last question) the equally important
Content-Type headers (else clients would indeed need to infer the media type from the extension and/or the content itself), but without the
Obviously, once you rely on
Content-Encoding, this should work just as well, if you'd serve it with
gz.css (or no extension at all for that matter), however, as outlined above, this might actually turn out to be misleading to downstream clients, insofar they do not not necessarily have to deal with an gzip encoded file anymore (a proxy might have decoded it already for example).