fix(standalone): resolve env var references in config pushed via Admin API

[AlinsRan]

TL;DR

In standalone mode, ${{VAR}} references in config pushed via the Admin API are stored literally (never resolved), so a reference in a pattern-constrained field (e.g. proxy-rewrite.uri) is even rejected with 400.

Cause

Standalone has two config sources; only the file path resolves ${{VAR}}:

• File (apisix.yaml): resolved in core/config_yaml.lua parse(), before schema validation.
• Admin API (admin/standalone.lua update()): validates and stores the JSON body without ever calling resolve_conf_var.

The divergence was introduced by #13078, which moved resolution into the file-parse path only.

Fix

update() now calls file.resolve_conf_var(req_body) before validate_configuration, mirroring the file path. Both the schema check and the stored config see resolved, natively-typed values — resolve_conf_var coerces resolved scalars to their native type (e.g. "2" → 2), and an unresolvable reference (no env var, no :=default) now fails fast with 400 instead of being stored literally.

Scope: this resolves the ${{VAR}} syntax only. $ENV:// / $secret:// references are a separate, lazily-resolved mechanism and are unaffected.

Test

t/admin/standalone.spec.ts, Variable resolution:

• ${{VAR:=default}} in proxy-rewrite.uri resolves and the route returns the hello body (a literal value would not match);
• ${{VAR:=2}} into the integer upstream.retries returns 202 (native-type coercion; a literal "2" would fail integer validation);
• an unresolvable ${{VAR}} returns 400 with failed to resolve variables in config.

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 (N/A)
• I have verified that the changes pass the existing tests