docs: correct Hubris hardware access description

- Replace inaccurate "unforgeable access tokens" with correct description
- Change "Minimal HAL" to "Direct Register Access" for clarity
- Remove capability-based permissions terminology that doesn't apply to Hubris
- Accurately describe that tasks directly manipulate hardware registers
- Clarify that permissions are statically configured at compile time

Author: rusty1968

docs/src/design/os-selection.md

@@ -50,7 +50,7 @@ Platform root of trust implementations require predictable response times for se
 
 | Feature | Hubris (Oxide) | Tock | Why it matters |
 |---------|----------------|------|----------------|
-| **Hardware Abstraction** | **Minimal HAL**: Direct hardware access through capability-based permissions (unforgeable access tokens). Each task gets explicit hardware rights. | **Capsule-based**: Higher-level interfaces to hardware resources through Tock's capsule abstraction layer. | Direct access with explicit permissions makes system behavior predictable and easier to audit for security compliance. |
+| **Hardware Abstraction** | **Direct Register Access**: Tasks directly manipulate hardware registers with no abstraction layer. Each task gets explicit hardware permissions defined at compile time. | **Capsule-based**: Higher-level interfaces to hardware resources through Tock's capsule abstraction layer. | Direct register access makes system behavior predictable and easier to audit for security compliance. |
 | **Design Philosophy** | **Reliability-focused**: Emphasizes static validation, correctness and predictability over flexibility. Avoids unsolved problems and unnecessary complexity, prioritizing correctness and reliability by construction for high-stakes server management. | **Application-flexible**: Designed for general-purpose embedded systems with dynamic application loading. Targets applications beyond Rust that can be dynamically loaded/replaced/removed separately from kernel, similar to traditional desktop/server OS but for resource-constrained settings. Platform supporting diverse embedded applications including security-critical systems. | Production systems require proven, stable interfaces while flexible platforms enable diverse application scenarios. Different philosophies serve different use cases and constraints. |
 | **System Composition** | **Static**: System composition fixed at build time with all dependencies resolved statically. Boot sequence is predictable and repeatable. | **Dynamic**: Runtime component loading and initialization. | Predictable system composition critical for server infrastructure where remote recovery from boot failures is expensive or impossible. |