docs: enhance OS selection analysis with XIP and memory efficiency improvements

- Add Memory Architecture and SRAM Efficiency analysis to comparison tables
- Correct technical understanding of both Hubris and Tock as XIP-capable systems
- Replace "Task Model" with "System Composition" for clearer terminology
- Update memory efficiency descriptions to use "suitable memory regions" terminology
- Improve accuracy of OS characterizations based on actual architectures

This enhances the technical accuracy and completeness of the OS evaluation framework.

Author: rusty1968

docs/src/design/os-selection.md

@@ -45,7 +45,7 @@ Complex embedded systems require robust debugging and monitoring capabilities th
 
 | Feature | Hubris (Oxide) | Tock | Why it matters |
 |---------|----------------|------|----------------|
-| **Task Model** | **Static**: All tasks defined at compile-time in app.toml configuration, cannot be created/destroyed at runtime. Build system validates all configurations with static assertions. Supports in-place task reinitialization for fault recovery - supervisor task can restart crashed tasks without system reboot. | **Dynamic**: Tasks can be dynamically loaded and assigned. Offers flexibility for diverse application scenarios and runtime adaptation. | Static model with compile-time validation prevents entire classes of runtime failures. In-place restart capability enables component-level recovery, avoiding system-wide reboots for isolated faults. Dynamic models provide flexibility for applications requiring runtime component loading or updates. |
+| **System Composition** | **Static**: All tasks defined at compile-time in app.toml configuration, cannot be created/destroyed at runtime. Build system validates all configurations with static assertions. Supports in-place task reinitialization for fault recovery - supervisor task can restart crashed tasks without system reboot. | **Dynamic**: Tasks can be dynamically loaded and assigned. Offers flexibility for diverse application scenarios and runtime adaptation. | Static model with compile-time validation prevents entire classes of runtime failures. In-place restart capability enables component-level recovery, avoiding system-wide reboots for isolated faults. Dynamic models provide flexibility for applications requiring runtime component loading or updates. |
 | **Communication** | **Strictly Synchronous**: IPC blocks sender until reply received. Uses rendezvous mechanism inspired by L4 microkernel - kernel performs direct memory copy between tasks, extending Rust's ownership model across task boundaries through leasing. | **Asynchronous**: Callback-based notifications for applications. | Synchronous communication eliminates race conditions, enables precise fault isolation (REPLY_FAULT at error point), and simplifies kernel design by avoiding complex message queue management. |
 | **Fault Isolation** | **Disjoint Protection Domains**: Drivers and kernel in separate, MPU-enforced memory spaces. Failing driver cannot corrupt kernel. | **Shared Protection Domain**: Drivers run in same domain as kernel but are partitioned by Rust's type system and capsule architecture. Capsules are kernel modules that rely on Rust's memory safety (borrowing rules, lifetime management) and trait-based interfaces for isolation rather than hardware memory protection. | Hardware-enforced isolation provides robust defense against faults. Memory-safe languages alone don't prevent all failures in critical systems. |
 
@@ -54,6 +54,7 @@ Complex embedded systems require robust debugging and monitoring capabilities th
 | Feature | Hubris (Oxide) | Tock | Why it matters |
 |---------|----------------|------|----------------|
 | **Resource Allocation** | **Fixed**: Memory, hardware, and IRQ allocation determined at build time. Static assertions verify total resource requirements don't exceed physical limits before compilation. Compile-time memory layout with predetermined regions that never change. | **Dynamic**: Resources allocated as applications load. Grant-based dynamic allocation with deterministic memory reclamation through Rust's ownership system and immediate cleanup on process termination. | Build-time allocation with static validation eliminates runtime resource exhaustion. Static allocation provides deterministic usage patterns, critical for long-running server infrastructure. |
+| **SRAM Efficiency** | **Maximum**: All code executes in-place from suitable memory regions. SRAM consumption limited to data, heap, and stack only. Static allocation enables compile-time SRAM usage validation. Build system customizes kernel to application, eliminating unused features and achieving optimal resource utilization. | **Optimal**: Kernel and applications execute in-place from suitable memory regions. SRAM consumed by runtime data only (stack, heap, process state). Tock's general-purpose kernel includes features for diverse application scenarios. | Both systems achieve excellent SRAM efficiency through XIP execution. Hubris achieves maximum efficiency through application-specific kernel customization and compile-time optimization, while Tock provides optimal efficiency with runtime flexibility and general-purpose kernel design. |
 | **Scheduling** | **Priority-based Preemptive**: Deterministic scheduling with strict priority ordering, higher priority tasks always preempt lower ones. | **Cooperative**: Kernel space cooperation with round-robin userspace scheduling. | Preemptive scheduling ensures critical security operations (cryptographic processing, attestation responses) can respond promptly and predictably, essential for platform trust establishment. |
 | **Debuggability** | **Kernel-aware Debugger**: Humility debugger co-developed with Hubris kernel provides deep system inspection through Debug Binary Interface (DBI). No in-application console interfaces or printf formatting. External debugger handles all formatting and command parsing, eliminating security vulnerabilities and code bloat. | **Traditional Console**: UART/USB-based console interfaces with in-application command parsing and printf-style formatting. Provides runtime system inspection and control capabilities. | Kernel-aware debugging eliminates security vulnerabilities from console interfaces while providing superior system observability. Traditional consoles introduce attack surface and code complexity but offer familiar debugging workflows. |