docs: Common anti-patterns page

## Gap

There is no single page that collects the recurring "what NOT to do" guidance we give customers. The same anti-patterns come up in evaluation conversations, support tickets, and architecture discussions, and customers benefit from a dedicated reference they can read before adopting a problematic approach.

## Proposed scope

A best-practices page collecting the anti-patterns below, each with: the principle, why it goes wrong, and the recommended alternative.

1. **Real-time / SSE updates during user sessions on front-end** — real-time delivers the trigger but customers still own the response (refetch timing, in-flight UI handling). Doesn't reduce design complexity, often multiplies it. Legitimate exceptions: internal admin UI, kiosks, monitoring dashboards, emergency kill-switches. Recommended default: fetch on session start.
2. **Chained / dependent feature flags** — use segmentation and traits for conditional logic instead.
3. **HTML content stored in remote config** — use a CMS.
4. **Localisation strings stored in flags** — use a CMS or localisation tooling.
5. **Adopting Edge Proxy before a demonstrated geographic or performance need** — adds operational overhead without benefit. See edge-proxy adoption decision guide.
6. **Storing PII as a persistent trait, or using PII as the identifier** — must be transient; the identifier should be non-PII (UUID or anonymised ID).
7. **Wrapping the Flagsmith SDK primarily for portability when not using OpenFeature** — OpenFeature already provides portability. Wrap on top of OpenFeature if you want custom entry points or naming conventions.
8. **Enabling production flag changes without change request approval** — use Change Requests to mitigate the single-developer-toggle risk in production environments.

This consolidates guidance currently scattered across SDK docs, governance docs, and our outbound communication.