[Fizz] Deduplicate <link rel="preload"> from Flight preload hints

[lllomh]

Summary

Fixes #35889

<link rel="preload" as="font" /> (and other preload types) rendered
inside an RSC component was appearing twice in SSR HTML when used
with Fizz SSR. This regression was introduced in 19.2.

Root cause:

When the RSC Flight server processes a <link rel="preload"> element, it
does two things:

1. Emits a Flight hint ('L' row) via processLink() in
   ReactFlightServerConfigDOM.js
2. Includes the <link> element in the serialized component output

During Fizz SSR, the Flight hint is received and dispatched to the Fizz
preload() function, which registers the resource in resumableState
and adds it to renderState.fontPreloads. Later, the same <link>
element from the component output is processed by pushLink(), which
fell through to pushLinkImpl(renderState.hoistableChunks, props) with
no deduplication check — producing a second identical link tag.

Fix:

In pushLink(), before emitting a <link rel="preload"> to
hoistableChunks, check whether the resource is already registered in
resumableState (using the same per-as-type tracking that preload()
uses: imageResources, styleResources, scriptResources, and
unknownResources for fonts and others). If already registered, return
null. If not yet registered, register it so future preload() calls
will also deduplicate correctly.

Test plan

• Added regression test does not duplicate font preload links from Flight hints during Fizz SSR in ReactFlightDOM-test.js that renders
  a <link rel="preload" as="font"> inside an RSC component through Fizz
  SSR and asserts the link appears exactly once in the HTML output.

[meta-cla]

Hi @lllomh!

Thank you for your pull request and welcome to our community.

Action Required

In order to merge any pull request (code, docs, etc.), we require contributors to sign our Contributor License Agreement, and we don't seem to have one on file for you.

Process

In order for us to review and merge your suggested changes, please sign at https://code.facebook.com/cla. If you are contributing on behalf of someone else (eg your employer), the individual CLA may not be sufficient and your employer may need to sign the corporate CLA.

Once the CLA is signed, our tooling will perform checks and validations. Afterwards, the pull request will be tagged with CLA signed. The tagging process may take up to 1 hour after signing. Please give it that time before contacting us about it.

If you have received this in error or have any questions, please contact us at cla@meta.com. Thanks!

[eps1lon]

Can you removed the unrelated code changes (package.json formatting, .yarnrc.yaml etc.)? The rest looks legit at glance but hard to validate with the other unrelated changes that we can't merge.

The Contributor License Agreement must also be signed before we can accept this change.