Admin/control plane should emit Server: AISIX/<version> response header

Context

PR #415 added Server: AISIX/<CARGO_PKG_VERSION> to every data plane response via a tower_http::SetResponseHeaderLayer::overriding(...) mounted on aisix-proxy::build_router. The independent audit on that PR surfaced a parallel gap on the admin/control plane:

aisix-admin's /metrics and admin endpoints today return no Server header. Out of scope for #415 (DP-only contract), but the same arguments apply: clients/intermediaries identifying the gateway, and never leaking an upstream Server if one ever bleeds through.

Smoke-test:

$ curl -sI http://127.0.0.1:<admin-port>/metrics
HTTP/1.1 200 OK
content-type: text/plain; ...
# no Server header

What this issue tracks

Mount an equivalent SetResponseHeaderLayer::overriding(header::SERVER, "AISIX/<CARGO_PKG_VERSION>") on aisix-admin::build_router so admin / metrics responses also carry the gateway identity. Cover with a lib-level test that asserts the header on a representative admin response (e.g. /metrics 200 and an admin-auth 401).

References

• PR #415 — data plane implementation, audit, and test pattern
• RFC 9110 §10.2.4 — product/version Server header format

Start in aisix-admin::build_router and compare its response-layer setup with the data-plane implementation from PR #415. Check the existing lib-level test structure, then cover /metrics and an admin-authenticated 401 response. Done means representative admin and metrics responses expose the AISIX version Server header while replacing any upstream value.