Cached flags collide between two client instances on different environments (cache not namespaced per environment)

When two Flagsmith client instances run in the same app on different environment keys with caching enabled, they can serve or overwrite each other's cached flags.

Use case: a host app uses the Flagsmith iOS SDK, and a third-party SDK embedded in the same app also uses the Flagsmith SDK, each configured with its own environment key against the same base URL.

Observed behaviour: with caching on, flags from one environment can be returned for the other, or the two instances overwrite each other's cached values.

Likely cause (to validate): the cache appears keyed on request URL only. The environment is sent as the X-Environment-Key header and the flags path is fixed, so two instances on the same base URL share a cache entry. On iOS this is compounded by Flagsmith.shared being a singleton.

Steps to reproduce:
1. Create two Flagsmith clients in one app, each with a different environment key, same API base URL, caching enabled.
2. Fetch flags on client A, then client B.
3. Observe client B serving client A's cached flags, or the two overwriting each other.

Proposed direction: namespace the cache per environment key so instances don't collide

Start by tracing the caching path used when two Flagsmith clients fetch flags, including how the request URL and X-Environment-Key header contribute to the cache key. Reproduce the two-client sequence from the issue with different environment keys against the same base URL, including the Flagsmith.shared singleton case. Done means each client consistently receives its own cached flags without overwriting the other instance's values.

Written by the indexing model from the issue text.