docs: expand anti-patterns with private state access guidance

Add 'Accessing Private State (Critical Anti-Pattern)' subsection to
DESIGN_PHILOSOPHY.md under Module Development anti-patterns.

Documents:
- Why getattr(obj, '_private', ...) is dangerous
- Code example showing the anti-pattern vs correct approach
- Guidance on when internal access seems needed
- Litmus test for detecting protocol violations

Motivated by microsoft/amplifier-app-cli#70 which shows this
anti-pattern spreading with 'Pattern from X' comments.

🤖 Generated with [Amplifier](https://github.com/microsoft/amplifier)

Co-Authored-By: Amplifier <240397093+microsoft-amplifier@users.noreply.github.com>

Author: colombod

docs/DESIGN_PHILOSOPHY.md

@@ -291,6 +291,34 @@ When faced with implementation decisions, ask:
 ❌ Failing to emit events for observable actions
 ❌ Crashing kernel on module failure (non-interference)
 
+### Accessing Private State (Critical Anti-Pattern)
+
+**Never use `getattr(obj, "_private", ...)` to reach into internal state.**
+
+This anti-pattern creates fragile code that breaks when internals change:
+
+```python
+# ❌ WRONG: Unwrapping internal layers to find what you need
+bundle_resolver = getattr(resolver, "_bundle", resolver)
+activator = getattr(bundle_resolver, "_activator", None)
+
+# ✅ RIGHT: Use public APIs or request the API be added
+activator = resolver.get_activator()  # Public contract
+```
+
+**Why this is dangerous**:
+1. Private attributes (`_name`) are implementation details - they change without warning
+2. Each unwrap layer multiplies the fragility
+3. "Pattern from X" comments mean the anti-pattern is spreading
+4. The "fix" creates more technical debt than the original problem
+
+**When you need internal access**:
+- If the functionality should be public → Add to protocol/interface
+- If it shouldn't be public → Redesign your approach
+- Never solve "I can't access X" by reaching into `_internal_X`
+
+**Litmus test**: Would this code break if the wrapped class's internal structure changed? If yes, you're depending on internals instead of contracts.
+
 ### In Design
 
 ❌ Over-general modules trying to do everything