Yes and no? The answer isn't totally straightforward, because of how SkSL (assuming you're using SkRuntimeEffect) works. The docs
try to lay this out, but it's not always clear once you're curious about low level details like this:
SkSL doesn't offer derivatives as a user-facing feature (yet). Texture samples can use the "correct" mip level, though. When you write an SkSL shader, you don't reference textures directly ... you reference SkShader objects. The most common one of those is an SkImageShader. When you create an SkImageShader from an SkImage, you specify the SkSamplingOptions, which controls what kind of filtering is performed, etc. So: When you do a draw with an SkSL shader that evaluates an SkImageShader, the user SkSL (that you wrote) doesn't really know anything about the underlying shader it's calling (all SkShaders have a consistent function signature in the mega-fragment shader that gets built). The implementation of the image shader will use the hardware APIs `sample` (or similar) intrinsics, and those will do mip filtering (assuming your SkImage has mipmaps, and your SkSamplingOptions specify that you want mipmap filtering).
For the second question: yes. The CPU backend can run any SkSL that is accepted by SkRuntimeEffect::MakeFor*. That's been true for a long time, from looking at git history, I'd say since about March 2021 (m90?). However, it's worth pointing out that the CPU backend does not implement derivatives for per-pixel mip selection, even when using SkSL. Because of the architecture in the previous paragraph, any evaluation of an image shader from SkSL defers to the existing image shader logic in the CPU backend ... and that continues to have the limitation it's always had (of picking a single mip level for the entire draw, although that "level" may be a fractional mix of two actual levels).