feat: expose js sdk identity on client metadata

[jonathannorris]

Summary

• extend ClientMetadata with JS-specific identity fields: sdk and framework
• set sdk in the base web and server clients
• expose framework metadata from the React, Angular, and Nest SDK layers so it is available on client.metadata and in hook clientMetadata

Motivation

Relates to #1375.

Today providers and hooks can access clientMetadata, but the JS SDKs do not expose enough identity to tell whether a call came from web vs server, or from react, angular, or nest.

Usage

const client = OpenFeature.getClient('my-domain');

client.metadata;
// web-sdk:
// {
//   domain: 'my-domain',
//   sdk: 'web',
//   providerMetadata: { name: '...' }
// }

hook.before = (hookContext) => {
  hookContext.clientMetadata;
  // react-sdk:
  // {
  //   domain: 'my-domain',
  //   sdk: 'web',
  //   framework: 'react',
  //   providerMetadata: { name: '...' }
  // }
};

Notes

• the framework SDKs use a small Proxy wrapper so framework metadata is visible both via client.metadata and from evaluations that read this.metadata
• this keeps the change isolated to the framework layers instead of expanding the core client constructor APIs

Related Issues

• Relates to [FEATURE] Expose JS SDK/framework identity on ClientMetadata #1375

[gemini-code-assist]

Code Review

This pull request introduces framework-specific metadata (Angular, Nest, and React) and SDK family identification ('web' or 'server') into OpenFeature clients. This is achieved by wrapping clients in a Proxy that intercepts metadata access. The changes include new utility functions for each framework, updates to the respective SDK providers/services to apply these wrappers, and expanded unit tests to verify metadata propagation. Review feedback highlights potential performance improvements in the Angular SDK, specifically regarding redundant client initialization in the directive and the need for caching proxied client instances in the service to avoid overhead during frequent flag evaluations.

[gemini-code-assist]

The initClient method is called both from the featureFlagDomain setter and from ngOnInit. When the domain is provided via an input binding, the setter will trigger initClient before ngOnInit runs, causing the client to be initialized twice and the first one to be immediately disposed. While not a functional bug, it is redundant.

[gemini-code-assist]

Creating a new Proxy wrapper on every call to getFlagDetails (which occurs for every flag evaluation via the service) introduces unnecessary overhead. Since OpenFeature.getClient() returns a singleton for a given domain, consider caching the proxied client instances within the service to improve efficiency.

[jonathannorris]

Hum... should sdk actually reuse Paradigm instead of introducing a new union on ClientMetadata?

Right now this PR uses sdk?: 'web' | 'server', but Paradigm is already 'server' | 'client'.

I think it probably makes sense to decide whether this field is meant to represent JS package family (web | server) or runtime paradigm (client | server) before we merge this.

[MattIPv4]

Hum... should sdk actually reuse Paradigm instead of introducing a new union on ClientMetadata?

Right now this PR uses sdk?: 'web' | 'server', but Paradigm is already 'server' | 'client'.

I think it probably makes sense to decide whether this field is meant to represent JS package family (web | server) or runtime paradigm (client | server) before we merge this.

Reusing makes sense to me. I think they are essentially representing the same thing? The server package sets its runsOn to 'server', and the web package sets its runsOn to 'client'. Seems silly to introduce a new union to also represent the same thing with different values?