fix: make enterprise inner API timeout configurable

[GareArc]

Replaces #39334, whose branch sat under hotfix/** and could not be updated (the hotfix ruleset requires changes go through a PR).

Problem

Requests to the enterprise inner API relied on httpx's implicit 5s default. No call site passed timeout, and no env or config could change it.

On tenants with enough installed apps, POST /webapp/permission/batch exceeds that budget and /console/api/installed-apps fails with httpx.ReadTimeout, so the Explore page cannot render.

Change

Adds ENTERPRISE_REQUEST_TIMEOUT to EnterpriseFeatureConfig and passes it to client.request in BaseRequest.send_request.

The name and int type deliberately match what already exists on main (added in #33158, which is not an ancestor of this branch). Using a different name here would leave two env vars controlling one behavior after this branch merges forward, silently orphaning any deployment configured on the other name.

Default is 90 on this branch. The enterprise server enforces its own SERVER_TIMEOUT (default 60s), so a client budget above that lets the server terminate a runaway request first and return a clean 504 instead of the two timers racing.

Note this raises the effective budget for all enterprise inner-API calls on this branch, not just the batch permission one — a stalled enterprise pod holds a gunicorn worker longer than it used to.

Also included: unrelated CI fix

api/Dockerfile ran npm install -g npm@latest against a pinned NODE_PACKAGE_VERSION=22.22.0. npm 12 requires node ^22.22.2 || ^24.15.0 || >=26.0.0, so the install now fails with EBADENGINE and the API image cannot build:

npm error notsup Required: {"node":"^22.22.2 || ^24.15.0 || >=26.0.0"}
npm error notsup Actual:   {"npm":"10.9.4","node":"v22.22.0"}

This is a pre-existing float, not a regression from this change — the step passed on 2026-03-15 and broke when npm 12 raised its node floor. Pinned to npm@11 (engine >=22.9.0) so the build stops tracking npm's release schedule. Happy to split this into its own PR if preferred; it is bundled only because this PR cannot go green without it.

Scope

Mitigation, not a root-cause fix. It makes the Explore page slow rather than broken, and only when the request completes inside the window — the enterprise-side 60s cap still applies.

The underlying cause is a per-app N+1 in the enterprise permission/batch handler: it loops IsUserAllowedToAccessWebAppByAppID per app id, ~6 queries each, two of them against tables with no indexes. Fixed enterprise-side and tracked separately.

Main-branch equivalent: #39335.

Ref: CUS-1422