docs: make provider dependency chain explicit with documentation and tests

This addresses issue #19 by making the implicit provider dependency order
explicit and order-sensitive.

Changes:
1. Created PROVIDER_ORDER.md - comprehensive documentation explaining:
   - The provider hierarchy from outermost to innermost
   - Why each provider must be at its position
   - Order-sensitive pitfalls and what would break
   - Guidelines for adding new providers in the future

2. Added provider composition tests (providerComposition.test.tsx):
   - 13 comprehensive tests validating provider order and dependencies
   - Tests verify all providers mount correctly
   - Tests check that hooks only work inside correct providers
   - Tests validate async initialization (AuthProvider, TimezoneProvider)
   - Tests verify theme persistence and notification propagation

3. Updated App.tsx with inline documentation:
   - Added detailed provider order contract in JSDoc header
   - Inline comments explaining each provider's position
   - Reference to PROVIDER_ORDER.md for detailed rationale

4. Updated Web-Development.md:
   - Added new section 5.5 'Provider Order Contract'
   - Documents provider hierarchy and rationale
   - Links to comprehensive provider documentation
   - References regression test suite

All tests pass. TypeScript compilation succeeds. Build succeeds.
The provider order is now explicit and future refactors can validate
compliance through the regression test suite.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Docs/Web-Development.md

@@ -591,6 +591,72 @@ function BanCard({ isHighlighted }: BanCardProps): JSX.Element {
 
 ---
 
+## 5.5. Provider Order Contract
+
+The frontend wraps the application in multiple context providers. **The order in which these providers are nested is order-sensitive and critical for correct operation.** Future refactors must respect this contract or fail silently.
+
+### Provider Hierarchy
+
+From outermost to innermost:
+
+1. **ThemeProvider** — must be outermost; provides theme context to `AppContents` so it can determine the theme and pass it to `FluentProvider`
+2. **FluentProvider** — receives theme from `useThemeMode()` within `AppContents`; must wrap all Fluent UI consumers
+3. **NotificationProvider** — provides notification service to all descendants; placed before error boundaries
+4. **ErrorBoundary** (top-level) — catches catastrophic errors; placed before routing
+5. **BrowserRouter** — enables routing; must wrap `AuthProvider` (which uses `useNavigate()`)
+6. **AuthProvider** — validates session on mount; must be inside `BrowserRouter`; shows loading spinner while validating
+7. **TimezoneProvider** — must be inside authenticated context (inside `RequireAuth`); fetches timezone from backend on mount
+
+### Why This Order Matters
+
+**ThemeProvider must be outermost:**
+- `AppContents` calls `useThemeMode()` to get the current theme
+- Cannot call a hook outside its provider
+- `FluentProvider` receives the theme as a prop
+
+**FluentProvider must be inside AppContents:**
+- Needs to read `useThemeMode()` hook
+- Must wrap all Fluent UI components
+
+**NotificationProvider before ErrorBoundary:**
+- Error boundaries may emit notifications on error
+- Provides notification service to error recovery handlers
+
+**AuthProvider inside BrowserRouter:**
+- Uses `useNavigate()` internally for logout redirects
+- `useNavigate()` requires `BrowserRouter` context
+
+**TimezoneProvider last:**
+- Fetches timezone from backend (requires authentication)
+- Only needed for authenticated routes
+- Placed inside `RequireAuth` guard
+
+### Adding New Providers
+
+When adding a new provider in the future:
+
+1. Identify what it depends on (which hooks or APIs it calls)
+2. Identify what depends on it (which child components use it)
+3. Place it accordingly in the hierarchy
+4. **Update this section** with its rationale
+5. **Add or update tests** in `src/providers/__tests__/providerComposition.test.tsx` validating the order
+
+### Provider Order Regression Tests
+
+Comprehensive tests in `src/providers/__tests__/providerComposition.test.tsx` validate:
+
+- ✅ All providers mount without crashing
+- ✅ Providers are accessible from their descendant components
+- ✅ Order-dependent initialization works correctly (auth validation, timezone fetch)
+- ✅ Theme persistence works across re-renders
+- ✅ Notifications propagate correctly
+
+**Do not refactor the provider hierarchy without running these tests first.**
+
+For detailed context and rationale, see `src/providers/PROVIDER_ORDER.md`.
+
+---
+
 ## 6. Component Rules
 
 - One component per file. The filename matches the component name: `BanTable.tsx` exports `BanTable`.