fix: gracefully fall back to base snapshot when patch loading fails

[eseidel]

Summary

• Changes FML_LOG(FATAL) to FML_LOG(ERROR) in TryLoadFromPatch when PatchCache::GetOrLoad returns nullptr
• This allows ResolveIsolateData / ResolveIsolateInstructions in dart_snapshot.cc to fall through to SearchMapping and load the base app snapshot instead of crashing

Context

When a native iOS plugin (e.g., native_geofence) spawns a secondary headless FlutterEngine for background work, TryLoadFromPatch attempts to load the .vmcode patch for that engine. If loading fails for any reason (iOS background file access restrictions, Dart_LoadELF rejection, etc.), the FML_LOG(FATAL) kills the entire process via fml::KillProcess().

The fallback path already exists in dart_snapshot.cc — both ResolveIsolateData and ResolveIsolateInstructions call TryLoadFromPatch first, then fall through to SearchMapping if it returns nullptr. The FATAL log prevented this fallback from ever executing.

With this fix, the secondary engine runs unpatched (using the base snapshot) rather than crashing the app.

Fixes shorebirdtech/shorebird#3634

Test plan

• Verify existing patch loading still works for the primary engine (cache hit path unchanged)
• Verify that a secondary FlutterEngine spawned by a native plugin falls back to base snapshot instead of crashing

[eseidel]

Closing for now — need more information from the reporter about the actual failure mode before making a fix. The ERROR logs from PatchCacheEntry::Create (lines 35 and 56 of patch_cache.cc) should appear before the FATAL crash and tell us exactly why the patch load fails.