Make secret arrays configurable for select workflows

[ArBridgeman]

Summary

We need a better approach for secrets-inherit so inherited workflow secrets can be configured through BaseConfig defaults and overridden per workflow when needed. This should apply only to
secrets, not permissions.

Context

Today, the inherited-secrets behavior is too generic and needs a more explicit model. In the first iteration, we only want this for a small set of workflows controlled by custom projects:

• slow-checks.yml
• cd-extension.yml
• merge-gate-extension.yml

The goal is to define secret inheritance (by their string name) in BaseConfig with sensible defaults, while still allowing one or more values to be overridden easily.

Proposed behavior

• Add secret inheritance settings to BaseConfig.
• Support defaults for workflow secrets.
• Allow workflow-specific overrides of one or more secret values.
• Do not extend this to permissions.
• Allow workflows to opt out entirely by setting secrets to none / empty.

Template usage

These settings should be available in Jinja so the workflow template can conditionally emit the secrets: block, for example:

{% if workflow_settings.slow_checks.secrets %}
  secrets:
    {% for secret_name in workflow.secrets %}
    {{ secret_name }}: ${{ secrets.{{ secret_name }} }}
    {% endfor %}
  {% endif %}

If a workflow does not want any secrets passed, the rendered output should omit the secrets block entirely.

Acceptance criteria

• BaseConfig supports default secret inheritance settings.
• Workflow config can override one or more secret values.
• The implementation only affects secrets, not permissions.
• slow-checks.yml, cd-extension.yml, and merge-gate-extension.yml can use the new model.
• Jinja templates can conditionally render the secrets block based on config.
• A workflow can explicitly disable inherited secrets.
• zizmor inline ignores are removed.