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.

Start at usePaginationFragment().refetch() and trace networkCacheConfig through the operation descriptor and query loader to the network layer. Verify the existing refetch path and ensure the metadata shown in the issue reaches the network layer's cacheConfig without being dropped.

Written by the indexing model from the issue text.