Cap maxWorkers and bump heap to bound Fantom Metro memory (#56529)

[rubennorte]

Summary:

Fantom runs every test through a single shared Metro server (started in
globalSetup). Jest's default maxWorkers is numCpus - 1, so on a
high-core box (e.g. 176 CPUs) ~175 workers fire bundle requests at Metro
concurrently. Each in-flight request makes Metro materialize a full
dependency Graph (transformed modules, source maps, inverse-deps,
file-watcher subscription), which is hundreds of MB.

The per-test DELETE eviction added in D101652820 only releases that
memory after the bundle response completes, so the simultaneous in-flight
set still blows past the previous Node --max-old-space-size=8192 ceiling
in scripts/fantom.sh — the Metro process aborts with
FATAL ERROR: Ineffective mark-compacts near heap limit after just a
handful of test suites.

Two coordinated changes that balance throughput and safety:

• scripts/fantom.sh: bump the Node heap from 8 GB to 16 GB so we have
  headroom over the observed steady-state peak.
• private/react-native-fantom/config/jest.config.js: cap maxWorkers
  at min(numCpus - 1, 16). With 8 workers the heap peaked at ~3 GB
  (~400 MB / worker), so 16 workers fits comfortably under a 16 GB cap
  with ~40% headroom.

This is intentionally a balance rather than a hard worker cap — bumping
the heap alone would still leave 100+ in-flight graphs racing GC, and
capping workers alone leaves throughput on the table on big machines.

Changelog: [Internal]

Reviewed By: andrewdacenko

Differential Revision: D101791795

[meta-codesync]

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

[react-native-bot]

This pull request was successfully merged by @rubennorte in 0f9b8e4

^{When will my fix make it into a release? | How to file a pick request?}

[meta-codesync]

This pull request has been merged in 0f9b8e4.