Most of the codes defined in the WebDAV standard are assumed by most implementations and also to an extent by IETF's standardization efforts to be recognizable HTTP codes even in non-WebDAV situation. Those codes are only defined semantically in the WebDAV protocol, but they are considered broadly to be extended HTTP codes available for general usage as defined, simply with less defined semantics in those cases.

Which would seem to apply equally here: While the HTCPCP standard only indicates the semantics of the codes with respect to usage in HTCPCP scenarios, they are still code extensions to HTTP and available for use as defined, simply with fewer specified semantics.

Which is to say if you build your HTTP REST API using 418, we can all generally agree that the error from your API at that time is "I'm a teapot". Given that you aren't an HTCPCP endpoint, we just can't assume that we could then try HTCPCP-TEA to then try to brew tea, as we can't be sure that the semantics follow. Perhaps your REST API is simply a catalog of brewing equipment for purchase, and it still makes sense for some of your endpoints to fail with a 418. :)

It's unlikely for the IETF to assign 418 to a different HTTP-based or HTTP-like protocol with an entirely different and non-compatible definition, so even if 418 is laxly defined for HTTP proper, it's still "technically correct" in the sense that you can technically use it all you want and the only repercussions from the technical specs are if you implement it wrong in HTCPCP, there's no wrong way to use 418 in plain HTTP. ;)

https://http.cat/418