What is the difference between Content-Type...charset=X and Content-Encoding=X?

According to RFC 7231 - Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content, the Content-Encoding header contains a list of content coding values. Quoting the RFC:

Content coding values indicate an encoding transformation that has been or can be applied to a representation. Content codings are primarily used to allow a representation to be compressed or otherwise usefully transformed without losing the identity of its underlying media type and without loss of information. Frequently, the representation is stored in coded form, transmitted directly, and only decoded by the final recipient.

content-coding = token

All content-coding values are case-insensitive and ought to be registered within the "HTTP Content Coding Registry", as defined in Section 8.4. They are used in the Accept-Encoding (Section 5.3.4) and Content-Encoding (Section 3.1.2.2) header fields.

Section 8.4 says:

The "HTTP Content Coding Registry" defines the namespace for content coding names (Section 4.2 of [RFC7230]). The content coding registry is maintained at http://www.iana.org/assignments/http-parameters.

The registry currently lists:

br           Brotli Compressed Data Format                [RFC7932]     
compress     UNIX "compress" data format                  [RFC7230] Section 4.2.1
deflate      "deflate" compressed data ([RFC1951])        [RFC7230] Section 4.2.2
             inside the "zlib" data format ([RFC1950])
exi          W3C Efficient XML Interchange
gzip         GZIP file format [RFC1952]                   [RFC7230] Section 4.2.3
identity     Reserved (synonym for "no encoding" in       [RFC7231] Section 5.3.4
             Accept-Encoding)
pack200-gzip Network Transfer Format for Java Archives
x-compress   Deprecated (alias for compress)              [RFC7230] Section 4.2.1
x-gzip       Deprecated (alias for gzip)                  [RFC7230] Section 4.2.3

UTF-8 is a character encoding scheme that can't be used to transform arbitrary binary data losslessly (at least not in a way that would make any sense). It's simply wrong to set Content-Encoding to UTF-8. User agents might simply ignore the unknown value or discard the message and report an error. The correct place to set the character encoding scheme is the Content-Type header.

Optional parameter charset makes sense only for text-based content (Content-Types like text/plain, text/html, and such). Not all messages are text.

Content-Encoding means that the whole body has been encoded in some way (usually compressed). Typical values for this header are gzip and deflate. The recipient of this message should decode (e.g. ungzip) the body to get the original message.

I'm not even sure if UTF-8 makes any sense as a value for the Content-Encoding.