Export PreloadableConcreteRequest from relay-runtime's Flow types

[GregoryCollett]

Summary

relay-runtime's TypeScript declarations expose PreloadableConcreteRequest — it is defined in util/RelayConcreteNode.d.ts and re-exported from index.d.ts. The Flow types do not: the Flow definition only lives in react-relay (relay-hooks/EntryPointTypes.flow.js).

So this works for a TypeScript consumer but not the Flow equivalent:

import type {PreloadableConcreteRequest} from 'relay-runtime'; // ✅ TS  /  ❌ Flow

The compiler emits @preloadable $Parameters.js artifacts whose type is PreloadableConcreteRequest, so it's natural for eager query-loader code to want the type from relay-runtime alongside RequestParameters, ConcreteRequest, etc.

What this does (types-only)

• Moves the canonical Flow definition of PreloadableConcreteRequest down into relay-runtime/util/RelayConcreteNode.js — the same file/location the .d.ts uses — and exports it from relay-runtime's index.js, matching index.d.ts.
• react-relay's EntryPointTypes.flow.js now imports and re-exports it from relay-runtime instead of defining an identical local copy, so there's a single source of truth. Every existing import ... from 'EntryPointTypes' keeps working via the re-export.

The Flow definition is unchanged — it's relay's own existing one (out TQuery extends OperationType, phantom __phantom__?: ?TQuery). No runtime code changes.

Notes

• OperationType is imported into RelayConcreteNode.js from the sibling ./RelayRuntimeTypes (same import the .d.ts already uses); RelayRuntimeTypes does not import RelayConcreteNode, so no cycle is introduced.
• This aligns the Flow public surface with the already-published TypeScript surface; it does not change the TS declarations.