The second option fits closest with a RESTful API design, with the inherent benefits that come with it.
Taking each in turn:
1. Client altering the URL has the risk that you'll break the clients if you ever need to change the image identifier URL format for any reason.
2. Server provides multiple versions is best aligned with a RESTful approach, with the principle benefit that changing the URL format will not break existing clients. It also allows for extensibility which is potentially self descriptive and machine readable (with a small change) like this:
{
"user": {
"id": 1,
"image_profile": {
"url": "https://cdn.mydomain.com/abcd.jpg",
"versions": {
"100": "https://cdn.mydomain.com/abcd_mhdpi.jpg",
"150": "https://cdn.mydomain.com/abcd_lhdpi.jpg",
"300": "https://cdn.mydomain.com/abcd@2x.jpg",
"72": "https://cdn.mydomain.com/abcd_web.jpg"
}
}
}
}
...i.e. you could redefine the identifier as a "DPI" figure or something similar. I don't know how advanced your client applications are; but potentially they could look for the numerical "nearest match" of DPI for the screen size in use. You could then insert additional resolutions in future accordingly.
3. Server uses agent string avoids the risks of option 1; but the client application itself is best placed to make the decision on resolution because it knows more about the context.
Summary
Option 2 doesn't restrict you in any way; and is also the most resilient to avoiding breaking changes in future.