docs(satellite): add comprehensive status & health tracking documentation

Add 4 new documentation files covering the MCP Status & Health Tracking System (18 implementation phases) and update 6 existing files with cross-references to maintain modular documentation structure.

New files:
- status-tracking.mdx: 11-state status system, lifecycle flows, tool filtering
- event-emission.mdx: Event types, payloads, batching configuration
- log-capture.mdx: Server/request logging, buffering, privacy controls
- recovery-system.mdx: Automatic recovery detection, retry logic, tool preservation

Updated files with cross-links:
- architecture.mdx: Add Status Tracking, Event System, Log Capture sections
- tool-discovery.mdx: Add Status Integration, Recovery System sections
- process-management.mdx: Add Status Events, Log Buffering sections
- backend-communication.mdx: Add Events vs Heartbeat, Health Check sections
- commands.mdx: Add health_check command documentation
- hierarchical-router.mdx: Add Status-Based Tool Filtering section

Navigation:
- docs.json: Add "Status & Health Tracking" group to Satellite Development tab

Technical details:
- 11 status values (provisioning → online → offline/error/requires_reauth)
- Event batching: 3-second interval, max 20 per batch
- Retry logic: exponential backoff (500ms, 1s, 2s)
- Log storage: 100-line limit per installation
- Request logging privacy control via settings

Author: Lasim

development/satellite/architecture.mdx

@@ -284,31 +284,36 @@ For complete implementation details, see [Backend Polling Implementation](/devel
 
 ### Real-Time Event System
 
-**Event Emission with Batching:**
-```
-Satellite Operations          EventBus              Backend
-       │                         │                     │
-       │─── mcp.server.started ──▶│                    │
-       │─── mcp.tool.executed ───▶│ [Queue]            │
-       │─── mcp.client.connected ─▶│                    │
-       │                      [Every 3 seconds]         │
-       │                         │                     │
-       │                         │─── POST /events ───▶│
-       │                         │◀─── 200 OK ─────────│
-```
-
-**Event Features:**
-- **Immediate Emission**: Events emitted when actions occur (not delayed by 30s heartbeat)
-- **Automatic Batching**: Events collected for 3 seconds, then sent as single batch (max 100 events)
-- **Memory Management**: In-memory queue (10,000 event limit) with overflow protection
-- **Graceful Error Handling**: 429 exponential backoff, 400 drops invalid events, 500/network errors retry
-- **10 Event Types**: Server lifecycle, client connections, tool discovery, configuration updates
+The satellite emits typed events for status changes, logs, and tool metadata. Events enable real-time monitoring without polling.
 
 **Difference from Heartbeat:**
 - **Heartbeat** (every 30s): Aggregate metrics, system health, resource usage
-- **Events** (immediate): Point-in-time occurrences, user actions, precise timestamps
+- **Events** (immediate): Point-in-time status updates, precise timestamps
+
+See [Event Emission](/development/satellite/event-emission) for complete event types, payloads, and batching configuration.
+
+### Status Tracking System
+
+The satellite tracks MCP server installation health through an 11-state status system that drives tool availability and automatic recovery.
+
+**Status Values:**
+- Installation lifecycle: `provisioning`, `command_received`, `connecting`, `discovering_tools`, `syncing_tools`
+- Healthy state: `online` (tools available)
+- Configuration changes: `restarting`
+- Failure states: `offline`, `error`, `requires_reauth`, `permanently_failed`
+
+**Status Integration:**
+- **Tool Filtering**: Tools from non-online servers hidden from discovery
+- **Auto-Recovery**: Offline servers auto-recover when responsive
+- **Event Emission**: Status changes emitted immediately to backend
+
+See [Status Tracking](/development/satellite/status-tracking) for complete status lifecycle and transitions.
+
+### Log Capture System
+
+The satellite captures and batches two types of logs for debugging and monitoring: **server logs** (stderr output) and **request logs** (tool execution with full request/response data).
 
-For complete event system documentation, see [Event System](/development/satellite/event-system).
+See [Log Capture](/development/satellite/log-capture) for buffering implementation, batching configuration, backend storage limits, and privacy controls.
 
 ## Security Architecture
 

development/satellite/backend-communication.mdx

@@ -157,11 +157,11 @@ For detailed event system documentation, see [Event System](/development/satelli
 - Performance metrics collection
 
 **Terminate Process:**
-- Graceful shutdown with SIGTERM
-- Force kill with SIGKILL after timeout
 - Resource cleanup and deallocation
 - Final status report to Backend
 
+See [Process Management - Graceful Termination](/development/satellite/process-management#graceful-termination) for SIGTERM/SIGKILL shutdown details.
+
 ## Internal Architecture
 
 ### Five Core Components
@@ -375,6 +375,70 @@ server.log.info({
 4. Add comprehensive monitoring and alerting
 5. End-to-end testing and performance validation
 
+## Events vs Heartbeat
+
+The satellite communicates status and metrics through two distinct channels:
+
+**Events (Immediate):**
+- Emitted when actions occur (not delayed by heartbeat interval)
+- Point-in-time status updates with precise timestamps
+- Batched automatically (3-second interval, max 20 per batch)
+- Types: Status changes, logs, tool metadata, lifecycle events
+
+**Heartbeat (Periodic, every 30s):**
+- Aggregate metrics and system health
+- Resource usage statistics
+- Overall satellite status
+
+See [Event Emission](/development/satellite/event-emission) for complete event types and batching strategy.
+
+## Health Check Command
+
+The backend sends `health_check` commands for credential validation:
+
+**Command Structure:**
+```typescript
+{
+  commandType: 'health_check',
+  priority: 'immediate',
+  payload: {
+    check_type: 'credential_validation',
+    installation_id: string,
+    team_id: string
+  }
+}
+```
+
+**Satellite Action:**
+- Calls `tools/list` on MCP server with credentials
+- Detects auth errors (401, 403)
+- Emits `requires_reauth` status if validation fails
+
+See [Commands](/development/satellite/commands) for complete command reference.
+
+## Recovery Commands
+
+When offline servers recover, backend sends recovery commands:
+
+**Command Structure:**
+```typescript
+{
+  commandType: 'configure',
+  priority: 'high',
+  payload: {
+    event: 'mcp_recovery',
+    installation_id: string,
+    team_id: string
+  }
+}
+```
+
+**Satellite Action:**
+- Triggers re-discovery for the recovered server
+- Status progresses: `offline` → `connecting` → `discovering_tools` → `online`
+
+See [Recovery System](/development/satellite/recovery-system) for automatic recovery logic.
+
 <Info>
 The satellite communication system is designed for enterprise deployment with complete team isolation, resource management, and audit logging while maintaining the developer experience that defines the DeployStack platform.
 </Info>

development/satellite/commands.mdx

@@ -115,6 +115,44 @@ Each satellite command contains:
 4. Restart affected components
 5. Verify system integrity post-update
 
+### health_check
+
+**Purpose**: Validates MCP server credentials and connectivity
+
+**Priority**: `immediate`
+
+**Triggered By**:
+- Backend credential validation cron (every 1 minute)
+- Manual credential testing
+- OAuth token expiration detection
+
+**Payload Structure**:
+```json
+{
+  "check_type": "credential_validation",
+  "installation_id": "installation-uuid",
+  "team_id": "team-uuid"
+}
+```
+
+**Satellite Actions**:
+1. Find MCP server configuration by installation_id
+2. Skip stdio servers (no HTTP credentials to validate)
+3. Build HTTP request with configured credentials (headers, query params)
+4. Call `tools/list` with 15-second timeout
+5. Detect authentication errors:
+   - HTTP 401/403 responses
+   - Error messages containing "auth", "unauthorized", "forbidden"
+6. Emit status event:
+   - On auth failure → `requires_reauth` status
+   - On success → credentials valid (no status change)
+
+**Error Detection Patterns**:
+- HTTP status codes: 401, 403
+- Response body keywords: "auth", "unauthorized", "forbidden", "token", "credentials"
+
+See [Status Tracking](/development/satellite/status-tracking) for credential validation status flow.
+
 ## Command Lifecycle
 
 ### Creation