fix: required client init parameters should not trigger separate ClientOptions type

[Copilot]

UseSingletonInstance in ClientOptionsProvider treated all non-standard client parameters as requiring a separate client-specific ClientOptions class. But required parameters (no DefaultValue) never become properties on the options class—they're inlined as constructor parameters on the client. This caused unnecessary per-client options types when using @@clientInitialization with required parameters in multi-client scenarios.

Changes

• ClientOptionsProvider.cs: Added parameter.DefaultValue != null check in UseSingletonInstance so only optional parameters (which actually become options properties) trigger a separate client-specific options type. This aligns the singleton decision logic with BuildProperties, which already filters on DefaultValue != null.
• ClientOptionsProviderTests.cs: Added MultipleClientsWithRequiredCustomParametersShareSingletonOptions test covering the multi-client scenario where a required custom parameter should still share the singleton options.

Before/After

// Multi-client scenario with required init parameter
@@clientInitialization(KnowledgeBaseRetrievalClient, {
  parameters: KnowledgeBaseRetrievalClientOptions, // knowledgeBaseName: string (required)
});

Before: Generates KnowledgeBaseRetrievalClientOptions (separate, unnecessary options type)
After: Shares singleton <ServiceName>ClientOptions with other clients in the library