fix(secret): log an error when a secret reference cannot be resolved

[shreemaan-abhishek]

Description

An unresolvable $secret:// or $env:// reference silently falls back to the literal reference string:

refs[k] = fetch(v, use_cache) or v

The literal is then used verbatim as whatever the field is: a password, an API key, an AWS access key ID. Nothing tells the operator that resolution failed. On the cached path (use_cache = true, which is what plugin conf resolution in plugin.filter() uses) the error returned by the secret manager was swallowed entirely, so a missing /apisix/secrets/<manager>/<id> resource or an unset environment variable produced no log line at all.

The failure mode this surfaces in practice: the raw reference goes upstream as a credential, and the operator only sees the provider's rejection. A user hit exactly this with ai-proxy + Bedrock, where the unresolved reference ended up inside the SigV4 credential scope:

{"message":"Credential must have exactly 5 slash-delimited elements, e.g. keyid/date/region/service/term, got '$secret://aws/xxxx/secret-name/access-key-id/20260723/us-east-1/bedrock/aws4_request'"}

with no corresponding error in APISIX's log.

This PR keeps the existing fallback behaviour (documented, and changing it would break existing deployments) but makes the failure visible:

failed to resolve secret reference: $secret://vault/1/foo/bar, field: password, err: no secret conf, secret_uri: ...

It covers both failure shapes: a manager error (no secret conf, backend failure) and a reference that simply resolves to nothing (unset environment variable), which previously returned nil without an error on either path.

The now-duplicated log in the uncached branch is dropped, since the caller logs with more context (the field name).

Which issue(s) this PR fixes

N/A

Checklist

• I have explained the need for this PR and the problem it solves
• I have explained the changes or the new features added to this PR
• I have added tests corresponding to this change
• I have updated the documentation to reflect this change
• I have verified that this change is backward compatible (If not, please discuss on the APISIX mailing list first)