Computationally expensive key derivation whose difficulty is asymmetric
The immediately obvious way to do this is to use RSA in a large-public-exponent format.

That is, the server selects an RSA modulus, and a large public exponent (say, $e = 2^{2^{30}}+1$) [1]; if the RSA primes are safe primes, this practically eliminates the possibility that $e$ is not relative prime to either $p-1$ or $q-1$.  The server would internally compute the CRT parameters (which are the same size as for normal RSA with the same modulus size, and the large $e$ value does not complicate this computation), and publish the public parameters (the modulus and the large $e$ in some compressed format; e.g. if it's always in the form $2^{2^x}+1$, we might just denote $x$).  We would also select a good RSA encryption padding method, such as OEAP.

Then, we have $\mathcal{F}_C(Y) = \text{Depad}( Y^e )$ (where $\text{Depad}$ is the procedure for removing the RSA padding); to compute $Y$, the server would take $K$, randomly pad it, and then perform the RSA private transform.

The client would need to perform $O( \log e )$ modular multiplications to compute $\mathcal{F}_C$; by selecting $e$ sufficiently large, we can make this as expensive as we like.  And, while the inverse computation of $\mathcal{F}_S$ isn't exceptionally cheap (it's about as expensive as generating an RSA signature or doing an RSA public key decryption), it isn't that bad (and we could reduce the cost somewhat if we used multiprime RSA).  And, if the server had some RSA acceleration hardware (which is not rare), this can be even cheaper.

Obviously, this is not the normal use of RSA, either as a public key encryption method, or as a signature method.  It is still a valid use of the concept.



[1]: Note: I'm using $e$ to describe the public exponent we give to the client, not the cost factor (as the question used it).