[compiler] Fix a bug in GetOwnFastDataPropertyFromHeap, part 2

The first CL https://chromium-review.googlesource.com/c/v8/v8/+/3010281
had a small mistake: the GC predicate alone doesn't yet guarantee that
Ref creation will succeed (due to JSFunction still being fg-serialized).

Bug: chromium:1227279, v8:11957, v8:7790
Change-Id: I81772baa66e0f778b92a03ea7941a199d92d4857
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3013353
Auto-Submit: Georg Neis <neis@chromium.org>
Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75627}

src/compiler/heap-refs.cc

@@ -604,10 +604,7 @@ base::Optional<ObjectRef> GetOwnFastDataPropertyFromHeap(
   Handle<Object> value = broker->CanonicalPersistentHandle(constant.value());
   Handle<Object> possibly_wrapped = Object::WrapForRead<AllocationType::kOld>(
       broker->local_isolate_or_isolate(), value, representation);
-  // MakeRef will always succeed, because either {possibly_wrapped} is {value}
-  // or we allocated a HeapNumber via the local isolate, which is thus
-  // guaranteed to pass the gc predicate.
-  return MakeRef(broker, *possibly_wrapped);
+  return TryMakeRef(broker, *possibly_wrapped);
 }
 
 // Tries to get the property at {dict_index}. If we are within bounds of the