The case when no mesh can be retrieved from the shrinkwrap target object can be
retrieved was not handled. It was handled by `ensure_shrinkwrap_cache_data` but
the calling function didn't check if the cache was actually created.
`BKE_modifier_get_evaluated_mesh_from_evaluated_object` can return null for an
object that would usually have a mesh but the object has not been evaluated yet,
as can be the case when there is a depsgraph cycle.
From my current understanding, the issue existed without 83325d1fd. Changing the
hash just made the depsgraph do different scheduling decisions so that now the
shrinkwrap was evaluated before the target object. The order in which these two
things are evaluated is arbitrary when there is a depsgraph cycle.
Pull Request: https://projects.blender.org/blender/blender/pulls/143757