chore(axios,security-engineering-productivity): remove axios from run_cypress scripts

[azasypkin]

Summary

NOTE TO CODE OWNERS: I'm modifying code I don't own day to day. Please verify the changes still work as expected - for these migrations a quick run of the affected scripts/tests is worth more than a code-only review.

This PR removes the axios dependency for files owned by @elastic/security-engineering-productivity. Phase 3 of the axios migration tracked under #266556.

Why

Node.js 22 ships a native fetch API built on undici, and every browser Kibana targets supports fetch natively. Removing axios cuts one runtime dependency and continues the per-team rollout that mirrors the earlier node-fetch migration (#250719 and siblings).

Changes

Three files under x-pack/solutions/security/plugins/security_solution/scripts/run_cypress/, all developer/CI scripts that spin up serverless test projects and poll their readiness:

• parallel_serverless.ts - 5 axios calls (proxy healthcheck, ES _cluster/health, Kibana /api/status, ES root, Kibana login). Replaced with fetch + explicit res.ok check + typed await res.json(). Dropped the .catch(catchAxiosErrorFormatAndThrow) wrappers that wrapped AxiosError into FormattedAxiosError; replaced with inline throw new Error('${response.status}:${await response.text()}') that preserves status+body in the error message. Folded 'Content-Type': 'application/json' into the module-private API_HEADERS constant and unwrapped [ELASTIC_HTTP_VERSION_HEADER]: [INITIAL_REST_VERSION] to a bare string - axios was setting Content-Type implicitly for object bodies and silently joining the single-element array, neither of which fetch does.
• cloud_project_handler.ts - 4 axios calls (create project, delete project, reset credentials, status poll).
• proxy_project_handler.ts - same shape as cloud_project_handler.ts with proxy-specific URLs.

Both project_handler files: catch blocks previously had an if (error instanceof AxiosError) { log status:data } else { log message } branch; with fetch the AxiosError branch is now dead, so they collapse to a single this.log.error(${error.message}). The thrown error's message contains ${status}:${responseBody} to preserve the same diagnostic content.

The retry callbacks' error instanceof AxiosError && error.code === 'ENOTFOUND' checks (used to log a friendlier "URL not yet reachable" message during DNS failures) were replaced with (error as { cause?: { code?: string } }).cause?.code === 'ENOTFOUND' — Node fetch wraps the underlying network error on error.cause, so DNS failures still surface with cause.code === 'ENOTFOUND'. The one retry callback in proxyHealthcheck previously guarded its log behind if (error instanceof AxiosError); with fetch every error reaching that callback is HTTP/network-related, so the guard is dropped and the parameter omitted.

Removed the corresponding run_cypress/ entries from AXIOS_LEGACY_CONSUMERS in .eslintrc.js. New axios usage anywhere in this directory is now blocked by the existing global ban.

Behavior parity

• Status-based retry decisions unchanged: res.ok is true exactly for 2xx, matching axios's auto-throw on non-2xx + error.response.status === 200 checks.
• ENOTFOUND detection unchanged: fetch's wrapped cause.code matches axios's code for DNS failures.
• Error log content preserved: messages still include status code and response body where the original did.
• The catchAxiosErrorFormatAndThrow import (which would have required migrating the format_axios_error.ts utility owned by @elastic/security-defend-workflows) is no longer needed; that utility stays as-is for its other consumers and will be migrated in a later phase.

[kibanamachine]

💛 Build succeeded, but was flaky

• Buildkite Build
• Commit: b93049f

Failed CI Steps

• Serverless Investigations - Security Solution Cypress Tests #11

Metrics [docs]

✅ unchanged

cc @azasypkin

[dkirchan]

Is JSON.stringify(body) really needed here? In axios its not needed so I guess it does the serialization behind the scenes if its needed indeed. Right?

[azasypkin]

Right! Responded in Slack, but will duplicate here for the records:

Axios does JSON.stringify for request body (+adds a correct Content-Type) and JSON.parse for response body automatically. The native fetch is more low-level, it only accepts strings, Blob, FormData, ArrayBuffer, URLSearchParams, or a ReadableStream for a request body (if one passes object it will just call toString() on it that will result into something like "[Object]") and requires consumers to parse body manually with json(), text() and so on (e.g. for perf reasons you might not want to call JSON.parse automatically and pay for that).

Using native fetch requires more boilerplate for sure, maybe eventually, when we all use fetch we can have some higher-level abstraction

[kibanamachine]

Starting backport for target branches: 8.19, 9.2, 9.3, 9.4

https://github.com/elastic/kibana/actions/runs/25378278491

[kibanamachine]

💔 Some backports could not be created

Status	Branch	Result
❌	8.19	Backport failed because of merge conflicts
✅	9.2
✅	9.3
✅	9.4

Note: Successful backport PRs will be merged automatically after passing CI.

Manual backport

To create the backport manually run:

node scripts/backport --pr 267684

Questions ?

Please refer to the Backport tool documentation

[azasypkin]

💚 All backports created successfully

Status	Branch	Result
✅	8.19

Note: Successful backport PRs will be merged automatically after passing CI.

Questions ?

Please refer to the Backport tool documentation