feat(sdk-node): wire up tracer_provider.sampler from declarative config

[MikeGoldsmith]

Which problem is this PR solving?

tracer_provider.sampler in a declarative-config YAML is parsed and validated today but never applied to the SDK so startNodeSDK() falls back to the default sampler regardless of what the YAML asks for. This is the last gating wiring gap for declarative config in JS.

Fixes #6506.

Short description of the changes

• New getSamplerFromConfiguration(config) helper in sdk-node/src/utils.ts that returns undefined when no sampler is configured (letting TracerProvider use its default) or builds a Sampler via the existing buildSamplerFromConfig otherwise.
• start.ts now passes the resolved sampler to TracerProvider and drops the TODO (6506) comment.
• buildSamplerFromConfig distinguishes experimental variants (jaeger_remote/development, probability/development, composite/development) from truly unknown keys in its fallback warning. Both still fall back to ParentBased(AlwaysOn).
• Tests for getSamplerFromConfiguration and for the experimental-variant warn path.
• Changelog entry under Features.

Type of change

• New feature (non-breaking change which adds functionality)

How Has This Been Tested?

• npm test - 234 tests pass, including new coverage
• npm run lint clean
• Locally exercised against the declarative-config example in docs(configuration): add declarative config example for startNodeSDK() #6834
  • a sampler configured in YAML now configures the selected sampler instead of ignoring it and always returning adefault

Out of scope

• opentelemetry-sdk-trace-base/src/config.ts (loadDefaultConfig / buildSamplerFromEnv) is the env-var path used by the legacy BasicTracerProvider shim. It's still load-bearing for users not going through startNodeSDK() and is publicly exported. Rewriting it to use the configuration package is a separate breaking change and isn't required to unblock declarative-config.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 95.58%. Comparing base (ec5aa93) to head (64b011d).
⚠️ Report is 16 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #6847      +/-   ##
==========================================
+ Coverage   95.56%   95.58%   +0.01%     
==========================================
  Files         386      388       +2     
  Lines       13088    13159      +71     
  Branches     2998     3002       +4     
==========================================
+ Hits        12508    12578      +70     
- Misses        580      581       +1     

Files with missing lines	Coverage Δ
...ental/packages/opentelemetry-sdk-node/src/start.ts	97.05% <100.00%> (+0.02%)	⬆️
...ental/packages/opentelemetry-sdk-node/src/utils.ts	96.51% <100.00%> (-0.17%)	⬇️

... and 5 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[trentm]

Thanks. Looks good. See nit comment below.

A side note on my intent for the utility functions for the "create" step (creating SDK things from the ConfigurationModel). This is an eventual goal for internal design, not something to block this PR. I don't want to block PRs like this on my fledgling plan. Initial notes at #6785

• these utility functions are called create<SDK Thing>FromConfig
• they live in src/create-from-config.js
• they take specific *ConfigModel arguments. (E.g. for this PR I'd have createSamplerFromConfig(sampler?: SamplerConfigModel): Sampler | undefined)
• they throw if unable to create the thing described by the config
• they use checkConfigUse() as appropriate

[opentelemetry-pr-dashboard]

This PR has review comments. Review suggestions, whether from maintainers or automated reviewers, aren't always correct or required. Please evaluate each comment on its merits, then make sure each thread has a clear outcome.

For example, link to the commit if you applied a suggestion, explain why it wasn't applied, or ask a follow-up question.

Automation flags a PR for human review once every review thread has a reply or is marked as resolved.

Status across open PRs is visible on the pull request dashboard.