Optimistic pre-authentication cannot be configured for internal S4U KeytabCredential

### Describe the bug
KeytabCredential explicitly supports optimistic pre-authentication:
`public override bool SupportsOptimisticPreAuthentication => this.keytab != null;`
However, when using S4U delegation through KerberosAuthenticator, the required settings cannot be configured.
S4UProviderFactory internally creates its own KeytabCredential:
```
this.client = KerberosClient.CopyOrCreate(delegationClient, config, logger);
this.credential = new KeytabCredential(upn, keytab);
```
The factory and credential are not accessible to the caller.
As a result, the first authentication always requires the normal two-request flow:
AS-REQ without pre-authentication
KDC_ERR_PREAUTH_REQUIRED containing the EType information
Second AS-REQ with PA_ENC_TIMESTAMP
TGT is returned
In our environment the KDC selects AES256.
Optimistic pre-authentication would allow the first AS-REQ to already contain the encrypted timestamp, but this requires both AuthenticationOptions.PreAuthenticate and the appropriate EType information in KeytabCredential.Salts.
There is currently no public API to configure the internally created credential.

### To Reproduce
Use KerberosAuthenticator with a keytab and S4U delegation.
On the first S4U request, observe two AS-REQs. The first receives KDC_ERR_PREAUTH_REQUIRED; the second succeeds after the returned EType information has been applied.

### Expected behavior
Since KeytabCredential declares support for optimistic pre-authentication, the S4U API should provide a way to configure it as well.
For example, callers should be able to provide a configured KeytabCredential or otherwise provide the required pre-authentication/EType information to the internal S4U credential.
This would allow the initial TGT acquisition to complete with a single AS-REQ when the required information is already known.

### Additional context
This is separate from KerberosClient.CopyOrCreate() not preserving client properties.
Even if AuthenticationOptions.PreAuthenticate is copied to the internal client, the internally created KeytabCredential still has no EType information. Without Salts, KeytabCredential.CreateKey() falls back to RC4 instead of selecting the AES key from the keytab.

Start with KerberosAuthenticator and trace how S4UProviderFactory creates its internal KerberosClient and KeytabCredential. Reproduce the first S4U request and inspect AuthenticationOptions.PreAuthenticate, KeytabCredential.Salts, and keytab EType selection. Done means the S4U API exposes a way to supply the required credential or settings and the initial TGT acquisition can use optimistic pre-authentication when configured.

Written by the indexing model from the issue text.