You would think that's the case, but it appears not so :-/ The context during invoke has the image correctly attached to it, but not during execute, so null is returned. There is a fallback check but that's only for space image data (sima) which doesn't work when this template is used in other editors (like for Image empties or Camera backgrounds).

PropertyRNA *prop is already declared above, so this shadows. Just do:

prop = RNA_struct_find_property(&imaptr, "filepath");

All sub-layouts share the same block, so no need to query it again. Just pass the existing block.

Apparently the image is passed via the button context (and if that fails through the image editor context, and if that fails, directly queried from the image editor). This button context isn't available anymore when the File Browser calls the exec() callback. It would be nice to support restoring it, like we already restore the window, area & region context, but I'm not at all keen on it since the data passed to the button context might get freed while the File Browser is open. In practice it probably would be fine, at least for IDs, since these are only freed/reallocated over undo/redo, which cancels the file operation anyway. Still not keen about it.

So I'd say querying the data in the invoke() and storing it in the custom data is indeed the best way to go for now.
However, you don't need a separate struct and allocate memory for this. Just assign the image to op->customdata directly. And please add a comment, something like:

/* The image is typically passed to the operator via layout/button context (e.g.
 * #uiLayoutSetContextPointer()). The File Browser doesn't support restoring this context when
 * calling `exec()` though, so we have to pass it the image via custom data. */

Lastly, I'd suggest adding a poll() function that checks if image_from_context() succeeds, so it's grayed out in the UI and search menus if not.