fix: surface api_key/base_url resolution errors instead of discarding them

[albatrossflyon-coder]

Summary

• buildProvider discarded the error from c.cfg.Resolve() for both api_key and base_url with the blank identifier (apiKey, _ := ...)
• A malformed template, a failed \$(command) substitution, or a required \${VAR:?message} check firing all failed silently — the provider was then built with an empty/wrong value, and the resulting auth failure surfaced far from the real root cause, deep inside the provider's own request path instead of at config load time
• Fix: check and return both errors, wrapped with which field and provider ID failed

Deliberately scoped narrower than the issue's literal suggestion: the issue proposes failing whenever api_key resolves to empty, but that would be a real regression — Bedrock (AWS credential/profile auth) and Azure OpenAI with Entra ID both legitimately have no api_key configured. crush's resolver already supports opting into a hard failure per-provider via \${VAR:?message} syntax in the provider's own api_key template (documented in internal/config/resolve.go), so the actual bug here is the discarded resolution error, not missing empty-string validation.

Fixes #3011

Test plan

• go build ./...
• go test ./internal/agent/... — all pass, no regressions (pre-existing unrelated Windows path-separator failure in internal/agent/tools confirmed present on unmodified main too)
• Added TestBuildProviderSurfacesResolveErrors — confirms both api_key and base_url resolution failures (via \${VAR:?message}) now return an error naming the field and provider, instead of silently proceeding
• Semgrep (p/security-audit, p/secrets, p/golang, Trail of Bits Go rules) on the changed files — 0 findings