docs: add encapsulation boundary rules (Principle 7)

Add new principle to PYTHON_BEST_PRACTICES.md addressing the anti-pattern
of accessing private attributes via getattr(obj, '_internal', ...).

This documents:
- Why accessing private state is dangerous
- Real example from PR #70 showing the anti-pattern
- Correct approaches (expose public API, redesign)
- Litmus test for detecting the problem

Motivated by microsoft/amplifier-app-cli#70 which demonstrates
the anti-pattern spreading across the codebase.

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

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

Author: colombod

context/PYTHON_BEST_PRACTICES.md

@@ -98,6 +98,46 @@ from .config import load_config
 - Group with blank lines between sections
 - Combine `from x import a, b` for related items only
 
+### 7. Respect Encapsulation Boundaries
+
+**Never access private attributes (`_name`) from outside a class.** Private attributes are implementation details that can change without notice.
+
+| Pattern | Problem | Correct Approach |
+|---------|---------|------------------|
+| `getattr(obj, "_internal", None)` | Bypasses encapsulation | Request a public API |
+| `obj._private_attr` | Depends on implementation | Use protocol/interface |
+| Chained unwrapping: `getattr(obj, "_wrapped")._inner` | Fragile, compounds tech debt | Expose capability at top level |
+
+**Why this matters**:
+- Private attributes change without deprecation warnings
+- Each "unwrap" pattern creates coupling to internal structure
+- Bugs become hard to trace through layers of private access
+- The "fix" creates more tech debt than the original problem
+
+**Real anti-pattern** (from PR #70):
+```python
+# BAD: Reaching into private internals to find what you need
+bundle_resolver = getattr(resolver, "_bundle", resolver)  # Unwrap layer 1
+activator = getattr(bundle_resolver, "_activator", None)   # Unwrap layer 2
+```
+
+**Correct approach**:
+```python
+# GOOD: If you need activator access, expose it via public API
+# Option 1: Add property to the wrapper
+# Option 2: Pass activator explicitly where needed
+# Option 3: Design interface to not need internal access
+activator = resolver.get_activator()  # Public contract
+```
+
+**When you feel tempted to access `_private`**:
+1. **Stop** - This is a design smell, not just a code smell
+2. **Ask**: Why isn't this exposed publicly?
+3. **If it should be public**: Add it to the protocol/interface
+4. **If it shouldn't**: You probably don't need it; redesign the approach
+
+**Test**: *"Would this code break if the internal implementation changed?"* If yes, you're depending on internals.
+
 ---
 
 ## The Golden Rule