help request: APISIX custom authentication plugin secretRef support for ApisixConsumer

### Description

I need to support per-consumer credentials for a custom auth plugin behind APISIX Ingress Controller. Each consumer calls a ForgeRock IDP, so the plugin must send that consumer’s client_id/client_secret along with the token during introspection. Hardcoding credentials inside the ApisixConsumer works, but we must move them into Kubernetes Secrets (populated from Vault via ExternalSecret) so each consumer references its own secret via something like secretRef.

Example (works when hardcoded):

yaml
`consumer:
- name: test
ingressClassName: apisix
authParameter:
jwtAuth:
secretRef:
name: test-jwt
plugins:
- name: vendor-forgerock
enable: true
config:
username: test
client_id: "test-client"
client_secret: "test-secret"`

However, when I add fields like secretRef inside config, APISIX rejects the consumer with “the input data should be an empty table.

Requirement:

Store per-consumer client_id/client_secret in Vault → ExternalSecret → Kubernetes Secret
Reference those secrets from the plugin config, so the plugin reads credentials at runtime
Each consumer (100+ total) should have its own secret

Question: Since consumer-level plugins is mainly designed for built-in auth plugins (jwt-auth, key-auth, etc.), what’s the correct approach for a custom plugin that needs per-consumer credentials? How can we safely reference secrets per consumer without hardcoding them?

### Environment

- APISIX version (run `apisix version`): 3.17
- Operating system (run `uname -a`): Linux dashboard-shell-2kq85 5.14.0-611.41.1.el9_7.x86_64 apache/apisix#1 SMP PREEMPT_DYNAMIC Sat Mar 21 12:28:25 UTC 2026 x86_64 GNU/Linux
- Deployment Mode: Standalone with API Based Ingress Controller

Start by reproducing the consumer validation error with the provided APISIX 3.17 configuration and trace how consumer-level custom plugin configuration is handled. Check the controller and APISIX schemas for supported Secret references and document whether the requested per-consumer credential flow is supported or requires a new design; done means a confirmed safe approach or a clearly scoped implementation plan.

Written by the indexing model from the issue text.