wfctl secrets commands (loadSecretsConfig + runSecretsSetup) parse YAML directly — bypasses processImports merges

[intel352]

Summary

The wfctl secrets family of commands (get, validate, export, setup, etc.) parses the YAML config directly via loadSecretsConfig / runSecretsSetup, rather than going through config.LoadFromFile. This means the imports-merge work done in PR #550 (Secrets, SecretStores, Secrets.Config, Environments) is invisible to those commands.

Symptom

After #550 merges, configs that move secrets.entries, secretStores, or per-environment secretsStoreOverride into shared imports will:

• Look empty in wfctl secrets get / validate / export.
• Route to the wrong store (or fall back to defaultStore/provider) in wfctl secrets setup.

Reproduction

# main.yaml
imports:
  - shared.yaml

# shared.yaml
secretStores:
  vault:
    provider: vault
    config:
      address: https://vault.example.com
secrets:
  defaultStore: vault
  entries:
    - name: API_TOKEN

• wfctl infra align (post-fix(wfctl): R-A4 align rule consults top-level secrets.generate + entries (workflow#541) #550): PASS — sees imported store + entry.
• wfctl secrets get API_TOKEN: fails or routes to wrong backend (depends on which loader is hit).

Path forward

Replace the direct YAML unmarshal in loadSecretsConfig (path: TBD — tracked via grep in cmd/wfctl/secrets*.go) and runSecretsSetup with config.LoadFromFile. Both already operate on a known config path, so the change is mechanical.

Regression tests should cover:

• wfctl secrets get <name> from imported-only entry.
• wfctl secrets validate with imported secretStores and per-env override.
• wfctl secrets setup writes to the import-merged defaultStore.

Context

Surfaced by Copilot review on PR #550. Scope-cut from #550 to keep that PR focused on the original W-541 align-rule fix. The wfctl secrets refactor is a separate concern that needs its own PR + careful regression coverage.

Related: workflow#541, PR #550, follow-up companion to #551.