fix: reject consumer auth when secret reference fails to resolve

[shreemaan-abhishek]

Description

When a consumer authentication credential is configured with a secret reference ($ENV://... or $secret://...) and that reference fails to resolve (env var unset, or the secret object is missing), secret.lua's retrieve_refs preserves the literal reference string (refs[k] = fetch(v) or v). consumer.lua's create_consume_cache then indexes the consumer under that literal string, so a client that sends the literal reference string as its credential authenticates successfully (fail-open).

Reproduced with key-auth: a consumer with key-auth.key = "$env://MISSING" (env unset) authenticates a request sending apikey: $env://MISSING. The same fail-open shape affects basic-auth, hmac-auth, and jwt-auth HS* secrets, since all route through create_consume_cache.

Fix

Fail closed in create_consume_cache: skip indexing a consumer whose auth credential is unset or still an unresolved secret reference (secret.has_secret_ref(auth_conf)). Using has_secret_ref over the whole auth_conf (not just the lookup key) also covers plugins whose secret is not the lookup field (e.g. basic-auth password, jwt-auth HS secret). Also removes a latent nil-index case.

Test

Added a key-auth regression case: a consumer whose key is an unresolved env ref, then a request sending the literal ref is rejected 401. Verified it fails on the old code (returns 200) and passes with the fix.

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 (no user-facing config/API change; behavior-only hardening)
• I have verified that this change is backward compatible

[membphis]

This still needs CI confirmation before merge.

The current checks show the build (ubuntu-latest, linux_openresty, t/plugin/[a-k]*.t ...) shard failed, with other CI jobs still pending. Since this PR changes t/plugin/key-auth.t, that failed shard is directly relevant to the change.

GitHub does not expose the failed job logs yet while the workflow run is still in progress, so I cannot tell whether this is a flaky/infrastructure failure or a regression from the new test. Please inspect the logs once available, or rerun only after confirming it is unrelated. I would wait for this shard to be green, or for the failure cause to be clearly understood, before merging.