fix: recover from FR24 live-feed backends that return no flights

[JeanExtreme002]

Problem

The scheduled runs are red in both SDKs, always on the same tests: everything that goes through getFlights() / get_flights() comes back with 0 flights (assert 0 >= 100, IndexError, expected +0 to be above 29), while the airport and airline tests pass.

Example: Node run 29882853857, and Python run 29884728134.

Root cause

Not our bug — FR24 is serving a broken backend.

data-cloud.flightradar24.com/zones/fcgi/feed.js sits behind an AWS load balancer with at least two targets, visible in the x-fr24-fcgi response header:

backend	response
frontend-feed-002	~1500 flight entries, full_count ticking up each call
frontend-feed-001	zero entries, full_count frozen at 22684 for 20+ minutes

The degraded one answers HTTP 200 with a perfectly well-formed envelope — full_count set, stats.total populated — but no flight rows and stats.visible all zeros. Roughly half of all requests landed on it.

Two things turned a 50/50 coin flip into a deterministic failure:

1. The AWSALB cookie pins the session to a backend (confirmed 8/8 in both directions). Since Session persists cookies, once a test process landed on the broken target, every later call returned [] — which is exactly why all four flight tests failed together.
2. The degraded payload is structurally identical to a legitimately empty result (say, a bounds box over open ocean). No field in the response distinguishes them.

Fix

getFlights() / get_flights() now treat "zero entries while full_count > 0" as suspect: drop the AWSALB/AWSALBCORS cookies so the balancer re-rolls the target, then re-request, up to 4 retries. A successful response re-pins the session to the healthy backend, so the gamble is paid at most once per client. A genuinely empty query still returns [], just after spending the retry budget.

Shedding stickiness needs a targeted delete — clearCookies() would also drop _frPl, the login cookie, which shares the same jar. Hence the new deleteCookie / delete_cookie on the client (typed in index.d.ts).

Tests

New offline suites in both SDKs (testFeedRetry.js, test_feed_retry.py), 7 cases each, no network, using a client double: retry-then-succeed, bounded give-up, no retry on full_count: 0, no retry when the first response is healthy, caller filters preserved across retries, and the login cookie surviving a stickiness drop. They run in the PR gate, so they keep guarding this while FR24 is healthy.

Verification

• Node — eslint and tsd clean, 40 offline, integration 46/46 in 6 of 7 runs
• Python — flake8 and mypy clean, 41 offline, integration 46/46

Out of scope

• RetryPolicy does not treat HTTP 429 as transient, and it defaults to off (maxAttempts=1). A real gap, but not what broke these runs — left for a separate change.
• Two one-off failures seen locally (a 429 on clickhandler, and the airline-logo test) came from firing hundreds of requests within a few minutes, not from CI conditions.