Review/Improve Startup Config Template Rendering Code/Process using Sprig

Is your feature request related to a problem? Please describe.

At startup, the config loader reads files from $TEMPORAL_ROOT/config/ (default: config/) in precedence order — base.yaml, {env}.yaml, {env}_{zone}.yaml — or a single file specified by TEMPORAL_SERVER_CONFIG_FILE_PATH. For each file, the loader scans the first 1KB for # enable-template (loader.go:51, loader.go:273) to decide whether to render it as a Go/Sprig template. This approach has several silent failure modes:

• A typo like # enable-templates or a comment like # do-not-enable-template silently mis-triggers or disables rendering. A file full of {{ env "VAR" }} with a missing or misspelled comment loads as literal YAML with no clear error.
• A long header comment can push # enable-template past the 1KB scan window, silently disabling templating.
• strings.Contains matches any comment containing the substring enable-template, including unrelated comments like # to render this template using sprig add a comment as follows: # enable-template.

Describe the solution you'd like

Always render config files through the Go/Sprig template engine. Plain YAML passes through unchanged, so there is no downside. The change eliminates bugs and reduces code complexity:

I'd be happy to submit a pull request for this change if the approach is agreeable.

Describe alternatives you've considered

• Use a .yaml.tmpl extension to signal templated files — unambiguous and consistent with common convention.
• Add an explicit --config-templated flag or TEMPORAL_CONFIG_TEMPLATE_RENDER_WITH_SPRIG env var (default true).

Additional context

Relevant code in common/config/loader.go:

• Lines 51–52: enableTemplate, commentSearchLimit constants
• Lines 227–252: processConfigFile
• Lines 268–279: checkTemplatingEnabled