LaunchDarkly: Consolidate per-env segment overrides via environment context gating

## Summary

`integrations/launch_darkly/services.py:_create_segments_from_ld` creates one `Segment` per `(LD UserSegment, environment)` pair. For a customer with N environments, each logical LD segment becomes N Flagsmith segments named ` (Override for )`, with separate rules and conditions. On one project we looked at this week, this produced 1,033 project-wide segments for a handful of logical LD segments across 178 envs — all included in every env's DynamoDB document (`util/mappers/engine.py:210-212`), and a meaningful contributor to doc size overruns that break edge evaluation.

## Proposal

One Flagsmith segment per logical LD UserSegment. Preserve per-env identity membership via rules that combine an environment-context gate with the identity condition, using the engine's existing `$.environment.key` / `$.environment.name` context (`flag_engine/context/mappers.py:23-26`, evaluated natively in `flag_engine/segments/evaluator.py`):

```
segment "beta-users"
parent rule ALL
child rule ANY
child ALL: env.key == "" AND identity.key IN [...]
child ALL: env.key == "" AND identity.key IN [...]
...
```

No engine change required — the gate is evaluated by `_matches_context_value` the same way any identity condition is.

## Scope

- `_create_segments_from_ld` creates one segment per distinct LD UserSegment.
- Build its rules structure with per-env `env.key` gates for each env's identity membership, not as separate segments.
- FeatureSegment attachment still happens per (feature, env) — unchanged.

## Testing

- Import of one LD UserSegment across three envs with different membership produces **one** Flagsmith segment. Evaluation against identity `A` in env 1 returns membership; `A` in env 2 does not.
- Import of two distinct LD UserSegments produces two segments, both with env-gated rules.

## Not this issue

- Cleaning up existing imports (ad-hoc).