Improve resilience of flaky tests to infrastructure and environment failures

## Description

Among the flaky test (system tests, policy tests, pipeline tests) issues (for example: [here](https://github.com/elastic/integrations/issues?q=is%3Aissue%20state%3Aopen%20label%3A%22Team%3ASecurity-Service%20Integrations%22%20label%3Aflaky-test%20-label%3A%22Integration%3Acyera%22%20-label%3A%22Integration%3Agoogle_workspace%22)), we see recurring failure modes that are due to test infrastructure or the environment rather than to the packages under test. This issue summarizes those variants and suggests improvements in elastic-package to make tests more resilient.

## Observed failure variants

1. **Fleet / Kibana API (Serverless or managed)**
- `no_shard_available_action_exception` / `search_phase_execution_exception` (400/503) when creating or getting agent policies.
- `Package info for - does not exist` (404) when adding a package policy (timing/propagation).
- `connection reset by peer` or `unexpected EOF` on requests to the Fleet/Kibana API (e.g. `POST .../api/fleet/package_policies`).
- *Impact:* Policy tests fail during apply/setup or cleanup.

2. **Concurrency / naming**
- `version_conflict_engine_exception` (409) when assigning a policy to an agent (concurrent update).
- `resource already exists` when creating a policy (duplicate name or leftover from a previous run).
- *Impact:* System or policy tests fail intermittently under parallel or repeated runs.

3. **Pipeline / Simulate API**
- `connection reset by peer` when reading the Simulate API response during pipeline tests.
- *Impact:* Pipeline tests fail during “simulating pipeline processing”.

## Benefits
1. **Fewer false failures and less triage**
Transient infrastructure failures (Fleet `no_shard_available`, connection resets) would be retried automatically instead of failing the run. That cuts down “flaky” test noise, reduces time spent re-running or triaging non-bugs, and makes real package/regression failures easier to spot.

2. **Faster, more reliable CI and developer trust**
Resilient test infra (retries, backoff, idempotent policy create/assign) means CI results are more stable without extra manual re-runs. Developers get clearer signal from red vs green, and parallel or repeated test runs become more reliable, so iteration speed and trust in automation both improve.