Harden on-demand JS segment load path against missing cache file

[javache]

Summary:
Harden the on-demand (lazily code-split) JS segment load path against a missing cache file.

When RN lazily loads an on-demand JS segment, the file lives in an OS-purgeable / LRU-evictable on-demand cache and can already be gone by the time the segment is registered. On a missing file JSBigFileString::fromPath throws std::runtime_error("... Could not open file: ..."), and ReactInstance::registerSegment had no failure handling, so the throw surfaced as an unhandled JS exception and crashed the app.

Fix (V4, addresses pieterdb's latest review feedback):

• JSBigFileString::fromPath's throwing contract is now documented in the header: it throws std::runtime_error when the file cannot be opened or read, and callers loading files that may legitimately be gone (an OS-purgeable / LRU-evictable cache) must catch and degrade gracefully. No behavior change to fromPath and no new factory.
• ReactInstance::registerSegment builds the segment buffer on the calling thread (outside the scheduleWork callback) inside a try/catch. On the thrown exception it logs an ERROR and returns early, so a missing segment never schedules evaluation and the throw no longer escapes. The buffer is carried into the callback as a std::shared_ptr<const JSBigFileString> (RuntimeScheduler callbacks are copyable std::functions; evaluateJavaScript takes const shared_ptr<const Buffer>&). This keeps file I/O off the JS thread.
• Dropped the inline access(R_OK) pre-check: the open() failure inside fromPath is the single source of truth, removing the redundant check and its TOCTOU window.

Changelog:
[iOS][Fixed] - Avoid an unhandled exception in bridgeless ReactInstance::registerSegment when an on-demand JS segment file is missing from the cache at lazy-load time

Reviewed By: zeyap, javache

Differential Revision: D114761643

[meta-codesync]

@javache has exported this pull request. If you are a Meta employee, you can view the originating Diff in D114761643.

[meta-codesync]

This pull request has been merged in fff4994.