Add process forking warning to Python Core SDK documentation

- Add comprehensive warning about not forking processes after Statsig initialization
- Include technical explanation of threading/async runtime issues
- Provide correct examples for uWSGI and Gunicorn deployment scenarios
- Show incorrect initialization pattern to avoid
- Offer lazy initialization as alternative solution
- Addresses potential deadlock scenarios in production WSGI deployments

Co-Authored-By: xin@statsig.com <xin@statsig.com>

Author: devin-ai-integration[bot]

docs/server-core/python/_faqs.mdx

@@ -0,0 +1,117 @@
+## Process Forking and WSGI Servers
+
+### ⚠️ Warning: Do not fork processes after Statsig initialization
+
+**Important:** Never fork processes after calling `statsig.initialize()`. Doing so will put Statsig in a weird state and may cause deadlocks.
+
+The Python Core SDK uses internal threading and async runtime components that do not work correctly when copied across process boundaries. When a process forks after initialization, these components can become corrupted, leading to:
+
+- Deadlocks in event logging
+- Hanging initialization calls
+- Unpredictable SDK behavior
+- Silent failures in feature evaluation
+
+### Correct initialization for WSGI servers
+
+For production deployments using WSGI servers like uWSGI or Gunicorn, ensure Statsig is initialized **after** the worker processes are forked, not in the main process.
+
+#### ✅ Correct: uWSGI example
+
+```python
+# app.py
+from statsig_python_core import Statsig, StatsigOptions
+from flask import Flask
+
+app = Flask(__name__)
+statsig = None
+
+def init_statsig():
+    global statsig
+    if statsig is None:
+        options = StatsigOptions()
+        options.environment = "production"
+        statsig = Statsig("your-server-secret-key", options)
+        statsig.initialize().wait()
+
+# Initialize in each worker process
+@app.before_first_request
+def before_first_request():
+    init_statsig()
+
+@app.route('/')
+def index():
+    # Use statsig here
+    return "Hello World"
+```
+
+```ini
+# uwsgi.ini
+[uwsgi]
+module = app:app
+master = true
+processes = 4
+# Statsig will be initialized in each worker process
+```
+
+#### ✅ Correct: Gunicorn example
+
+```python
+# gunicorn_config.py
+def post_fork(server, worker):
+    # Initialize Statsig after worker process is forked
+    from app import init_statsig
+    init_statsig()
+
+# app.py - same as uWSGI example above
+```
+
+```bash
+# Start Gunicorn with post-fork hook
+gunicorn --config gunicorn_config.py app:app
+```
+
+#### ❌ Incorrect: Initializing before fork
+
+```python
+# DON'T DO THIS - initializing in main process before fork
+from statsig_python_core import Statsig, StatsigOptions
+
+# This runs in the main process
+options = StatsigOptions()
+options.environment = "production"
+statsig = Statsig("your-server-secret-key", options)
+statsig.initialize().wait()  # ❌ This will cause issues when workers fork
+
+app = Flask(__name__)
+# Workers inherit the initialized statsig instance - this causes problems!
+```
+
+### Alternative: Use lazy initialization
+
+If you cannot control the forking behavior, use lazy initialization to ensure Statsig is only initialized when first needed in each process:
+
+```python
+import threading
+from statsig_python_core import Statsig, StatsigOptions
+
+_statsig = None
+_statsig_lock = threading.Lock()
+
+def get_statsig():
+    global _statsig
+    if _statsig is None:
+        with _statsig_lock:
+            if _statsig is None:  # Double-check locking
+                options = StatsigOptions()
+                options.environment = "production"
+                _statsig = Statsig("your-server-secret-key", options)
+                _statsig.initialize().wait()
+    return _statsig
+
+# Use get_statsig() instead of direct statsig access
+@app.route('/')
+def index():
+    statsig = get_statsig()
+    # Use statsig here
+    return "Hello World"
+```