feat(runs): apply settings to the run spec at run creation

[davidlin20dev]

Tracking issue

Related to #7775. This closes task 3.1. Related to #7932.

Why are the changes needed?

Settings can be stored and resolved, but nothing reads them, so a run's queue and concurrency still come only from the request or from static config. This is the first applier: it makes a stored setting change what a run actually does.

What changes were proposed in this pull request?

• applyRunSettings in runs/service/settings_apply.go fills RunSpec.queue and RunSpec.max_action_concurrency when the request leaves them unset. An explicit request value always wins, and a setting that is INHERIT or UNSET contributes nothing.
• CreateRun resolves settings once, right after the run spec is normalized and before the static config defaults below it. A failed lookup returns CodeInternal rather than continuing, since the settings table shares the database with runs.
• RunService takes a SettingsRepo; setup.go and the api test harness now share one instance with the settings service.

How was this patch tested?

• Table test over applyRunSettings: value applied, explicit request value wins, INHERIT and UNSET contribute nothing, empty settings and a nil spec are safe.
• TestCreateRun_AppliesSettingsQueue drives CreateRun with no queue in the request and asserts the settings value is both persisted and passed to Enqueue.
• Existing run service tests pass with a settings repo that reports no rows, so behavior is unchanged when nothing is configured.

Labels

• added

Check all the applicable boxes

• I updated the documentation accordingly.
• All new and existing tests passed.
• All commits are signed-off.

Related PRs

Stacked on #7956. Builds on #7841, #7859, #7900, #7925, #7927 and #7937.

[AdilFayyaz]

The OSS decision was to not support orgs, ( #7157 removed it from every table and service, and the backend is meant to ignore it). The settings key shouldnt take org from the request. The SDK derives an org from the endpoint hostname, so a named run can look up v1:<host>:: and miss the row scheduled runs hit.
Maybe EncodeSettingsKey can ignore org, so settings are stored and looked up under the same key no matter what the client sends

[davidlin20dev]

Makes sense, thanks for the review! Unnamed runs drop the org as well, so the fix covers that path too. I'll make EncodeSettingsKey ignore org in a separate PR and remove the org note from this one.