usePaginationFragment().refetch() should pass networkCacheConfig through to the network layer

I’d like usePaginationFragment().refetch() to support passing networkCacheConfig through to the final Relay network request. Today, when calling refetch with:

refetch(
	variables,
	{
		fetchPolicy: 'network-only',
		networkCacheConfig: {
			force: true,
			metadata: {
				latestWinsKey: 'some-key',
			},
		},
	},
);

the network layer receives a cacheConfig like:

{ force: true } but the metadata field is not preserved. This makes it difficult for product network layers to make opt-in per-request decisions based on cacheConfig.metadata, such as request cancellation, request classification, tracing, or custom fetch behavior.

Motivation

We have a paginated/refetchable fragment where user input can trigger repeated refetches quickly, for example:

1. user searches JJJ
2. user quickly changes search to JJJT
3. the JJJT request returns first and renders correct results
4. the stale JJJ request returns later and overwrites the UI with stale results We want the product network layer to opt this specific request family into “latest wins” behavior by passing metadata with the refetch request:

refetch(
	{
		id,
		filters: {
			searchTerm,
		},
	},
	{
		fetchPolicy: 'network-only',
		networkCacheConfig: {
			force: true,
			metadata: {
				latestWinsKey: `capacity-planning:work-table:${id}`,
			},
		},
	},
);

Then the network implementation could use:

Network.create((request, variables, cacheConfig) => {
	const latestWinsKey = cacheConfig.metadata?.latestWinsKey;
	// abort/suppress previous in-flight request with the same key
});

However, the metadata does not currently reach the network layer from usePaginationFragment().refetch().

Expected behavior

networkCacheConfig passed to refetch should be forwarded to the operation descriptor / query loader and eventually arrive at the network layer as the cacheConfig argument:

refetch(
	variables,
	{
		fetchPolicy: 'network-only',
		networkCacheConfig: {
			force: true,
			metadata: {
				latestWinsKey: 'my-key',
			},
		},
	},
);

Network layer should receive:

{
	force: true,
	metadata: {
		latestWinsKey: 'my-key',
	},
}

Actual behavior

The network layer receives:

{
	force: true,
}

The metadata field is dropped or not propagated.

Why this is useful

cacheConfig.metadata is a good place for product-specific network-layer behavior because it avoids hardcoding behavior by operation name inside the network implementation. Examples:

• latest-wins cancellation for search/refetch requests • custom request classification • tracing or analytics metadata • transport-layer feature flags • request-specific routing hints

Without this, consumers either need to:

1. hardcode behavior in the network layer by operation name / variables, or
2. avoid usePaginationFragment().refetch() and use a different query-loading API, or
3. patch Relay locally.