fix(basic-auth): validate anonymous_consumer against schema

[shreemaan-abhishek]

Description

In basic-auth, the anonymous_consumer field is declared as a sibling of properties instead of inside it:

local schema = {
    type = "object",
    properties = {
        hide_credentials = { ... },
        realm = schema_def.get_realm_schema("basic"),
    },
    anonymous_consumer = schema_def.anonymous_consumer_schema,   -- never applied
}

anonymous_consumer is not a JSON-Schema keyword at that level, and the schema does not set additionalProperties = false, so core.schema.check() silently ignores it. The field is therefore never validated: anonymous_consumer can be a number, a boolean, a table, or an empty string and check_schema still returns true. rewrite() then hands that value straight to consumer.get_anonymous_consumer(), which expects a string.

The other three auth plugins place the field correctly inside properties — see key-auth.lua:38, jwt-auth.lua:63, hmac-auth.lua:78 — so basic-auth is the outlier. The field was introduced in #11917.

This PR moves anonymous_consumer into properties, so it is validated as the non-empty string it is already documented to be.

Impact is limited to misconfiguration: there is no authentication bypass, and a correctly-configured anonymous_consumer (a string) behaves exactly as before. Configs that set a non-string value now fail admin-API validation instead of being accepted and failing later at request time.

No documentation change is needed — docs/en/latest/plugins/basic-auth.md already documents anonymous_consumer as string, matching the other auth plugins; the code was what disagreed with the docs.

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 (docs already describe the intended behavior; no change required)
• I have verified that this change is backward compatible (If not, please discuss on the APISIX mailing list first)