fix(e2e): rework kubernetes gateway connectivity test for the PAM accounts model

[claude]

Requested by Sheen · Slack thread

Before / After

Before: TestGateway_RelayGatewayConnectivity fails in CI — its kubernetes and redis subtests error because they create PAM resources via the removed POST /api/v1/pam/resources/{type} routes, which now return HTTP 404.

After: the kubernetes subtest is reworked to the revamped PAM account model and exercises gateway relay connectivity again; the redis subtest is skipped until redis PAM is re-added to the backend.

Why

The relay e2e job builds the backend from infisical/infisical's latest main (no version pin), so the generated e2e client (e2e/packages/client/client.gen.go) has drifted. The backend replaced the flat resources/{type} PAM creation with a folder + template + account model under /api/v1/pam/accounts/{type}, and does not yet implement redis as a PAM account type.

Changes

• e2e/relay/gateway_test.go — the kubernetes subtest now creates a PAM folder, a kubernetes account template, and a kubernetes account (pointed at the mock server), then asserts the gateway proxied the /version probe. The redis subtest is skipped with a TODO until redis PAM lands on the backend.
• e2e/openapi-cfg.yaml — whitelisted the createPamFolder, createPamAccountTemplate, and createKubernetesPamAccount operations.
• e2e/packages/client/client.gen.go — added client methods for those three operations to match the current backend routes. These were hand-added to match the whitelist; a full make generate-code against a current backend should reproduce them.

Notes

• The container-based e2e can't be run in the authoring environment (no docker daemon), so this is verified via CI.
• TestGateway_RelayGatewayConnectivity/redis remains skipped; re-enable once redis PAM is implemented as an account type.