Use cfg.NewProvider() in run flags to respect enterprise provider factory

[reyortiz3]

Summary

BuildRunnerConfig and configureMiddlewareAndOptions in run_flags.go were loading application config via cfg.NewDefaultProvider().GetConfig(). NewDefaultProvider always reads the global singleton and never checks a registered ProviderFactory. Any custom provider registered via RegisterProviderFactory — for example, one that merges OTEL config from an external source — would be silently bypassed on every thv run.

• Switch both call sites to cfg.NewProvider().LoadOrCreateConfig(), which checks registeredFactory first and falls back to the default path when no factory is registered
• Add TestSetupTelemetryConfiguration_LoadOrCreateConfigPath to document and guard the correct config-loading contract: LoadOrCreateConfig() on a PathProvider reads OTEL settings correctly, confirming the code path the fix enables

Type of change

• Bug fix

Test plan

• Unit tests (task test)
• Linting (task lint-fix)

Does this introduce a user-facing change?

No — deployments with no registered factory fall through to NewDefaultProvider as before. Deployments using a custom ProviderFactory now correctly pick up OTEL and other settings from that provider.

Generated with Claude Code

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 68.94%. Comparing base (00558da) to head (67c3d8e).
⚠️ Report is 6 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #4755   +/-   ##
=======================================
  Coverage   68.93%   68.94%           
=======================================
  Files         517      517           
  Lines       54441    54441           
=======================================
+ Hits        37528    37533    +5     
+ Misses      14044    14041    -3     
+ Partials     2869     2867    -2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[reyortiz3]

@claude can you verify if the comments have been addressed?

[claude]

Claude finished @reyortiz3's task in 45s —— View job

---

Review comment verification

• Read current run_flags.go to check comment 1 (double config loading)
• Read current run_flags.go to check comment 2 (setupRuntimeAndValidation using NewDefaultProvider)
• Post findings

---

Both review comments have been fully addressed in the current commits.

Comment 1 — Double config loading (line 699)

Resolved. configureMiddlewareAndOptions now accepts appConfig *cfg.Config as a parameter (line 694) rather than calling cfg.NewProvider().LoadOrCreateConfig() independently. Config is loaded once in BuildRunnerConfig and passed through, eliminating the double-load.

Comment 2 — setupRuntimeAndValidation still using NewDefaultProvider (line 323)

Resolved. setupRuntimeAndValidation now accepts configProvider cfg.Provider as a parameter (line 416) and passes it directly to runner.NewCLIEnvVarValidator(configProvider) (line 427). There are zero remaining calls to cfg.NewDefaultProvider() in run_flags.go.

The fix is consistent across all three call sites now — config is loaded once via cfg.NewProvider() in BuildRunnerConfig, and the resulting provider/config is threaded down to all consumers.