Regression: sun.net.http.allowRestrictedHeaders is not always respected for restricted headers

## Bug Description

In recent version 2.48, the behavior for handling restricted HTTP headers with the `HttpUrlConnector` is broken compared to prior Jersey release 2.47.

I am using Oracle OCI SDK 2.x

In Jersey 2.39.1, we saw
```
Attempt to send restricted header(s) while the
[sun.net.http.allowRestrictedHeaders] system
property not set. Header(s) will possibly be ignored
```

This is because OCI SDK sets Host header for whatever reasons

We thus added `sun.net.http.allowRestrictedHeaders` system property and life was good

With 2.48, this behavior reverted and we saw this message again even though the system property is set

A code review of v2.48 of `HttpUrlConnector` shows this exact logic was refactored into a configuration class. Debugger breakpoints show that the `HttpUrlConnectorConfiguration.ReadWrite#fromClient` method which reads this system property is called in some code paths but not in others leading to the broken behavior

Downgrading to 2.47 restores the expected and presumably correct behavior which further suggests this is a regression

---

What follows is copilot garbage which may or may not be accurate:

### Regression Detail
- Previously, the system property `sun.net.http.allowRestrictedHeaders` was checked directly in `HttpUrlConnector`. This ensured that setting the property at runtime (before client or target creation) consistently enabled or disabled sending restricted headers like `Origin`, `Host`, etc.
- Now, the check is performed only in `HttpUrlConnectorConfiguration.ReadWrite#fromClient(Configuration configuration)`. However, this method is not guaranteed to be called when constructing per-request configuration, so if the property is set or changed after the client is built, new requests may ignore the property—which is incorrect compared to the former behavior.
- The per-request configuration built via `fromRequest()` does not re-copy or re-check the cached property from the client configuration, leading to requests sometimes ignoring a property set by the user.

### Steps to Reproduce
1. Set `sun.net.http.allowRestrictedHeaders` **after** the Jersey client is initialized (but before a request is made).
2. Attempt to send restricted headers such as `Origin` or `Host` using the default `HttpUrlConnector`.
3. The headers are not sent, despite the property being set.

### Expected Behavior
- When `sun.net.http.allowRestrictedHeaders` is set to `true` before a request (but possibly after the client is created), any requests using the default connector should forward restricted headers.
- This was how previous releases of Jersey worked.

### Actual Behavior
- Requests may skip sending restricted headers, ignoring the system property even if it is set.

### Analysis
- The value of `sun.net.http.allowRestrictedHeaders` is only cached in the client configuration and not propagated into the per-request configuration in all cases. The old behavior checked the property at request time or always propagated its value.
- This is a regression breaking applications that rely on setting this property to use CORS or custom hosts.

### References
- [Current HttpUrlConnector.java (line 536)](https://github.com/eclipse-ee4j/jersey/blob/795e4acb73ca647d35c21c0738045d8ca18d3a05/core-client/src/main/java/org/glassfish/jersey/client/internal/HttpUrlConnector.java)
- [Current HttpUrlConnectorConfiguration.java](https://github.com/eclipse-ee4j/jersey/blob/795e4acb73ca647d35c21c0738045d8ca18d3a05/core-client/src/main/java/org/glassfish/jersey/client/internal/HttpUrlConnectorConfiguration.java)

### Proposed Fix
- Ensure that the `isRestrictedHeaderPropertySet` value is propagated from the client config into each per-request configuration (e.g., update `fromRequest()` to copy this field).
- Alternatively, check the system property in the per-request configuration or even at actual request execution time, as in the old code.