We're now entering the realm of what represents a caption and what doesn't. Given my earlier point that the figcaption text is mapped as the accessible name or description for screen reader users, interactive elements inside the caption should be avoided because they don't make sense when spoken inside a flattened, plain text string. So to answer the specific question, "now what?" Don't put the link inside the figcaption, put it inside the <figure> as a sibling of the image (or inside a container which is a sibling of the image).
To look at it another way: I might be inclined to say that caption text should make sense when presented with the accompanying image in a non-web context (e.g. a printout). This is why captions are often used for credit lines, attribution info, etc.
> I’m not convinced that there is a properly correct solution here.
Without a more specific use case, it's difficult to make a recommendation. However, I will say one thing that I've found to be universally true: the power of the image description is often underrated. I've had many conversations with designers, developers, content editors et al, where the assertion has been made that there's not much to describe in a particular image. And then as a blind user, I have multiple questions about what it shows, the answers to which can make it into the descriptive text.
This is often a lightbulb moment for many, as they realise that actually, all those details I asked about were subconsciously filled in/processed, and they just didn't think about them. Data is the same.