Remove deprecated API references and update error types

- Delete migration-zero-overhead.mdx (v0.2→v0.3 migration guide)
- Remove OLD DESIGN sections and version references from zero-overhead-ipc
- Update HorusError enum: remove Other, add Driver/Unsupported/Internal{}/Contextual{}
- Remove send_logged()/recv_logged() mentions from message-types
- Clean v0.3+ version references from topic and common-mistakes docs

Author: neos-builder

content/docs/concepts/core-concepts-topic.mdx

@@ -144,7 +144,7 @@ See [Communication Transport](/concepts/communication-transport) for detailed co
 
 ## Send and Receive
 
-> **Note**: HORUS v0.3+ uses a [zero-overhead IPC architecture](/concepts/zero-overhead-ipc) where introspection is separated from the hot path. The `send()` and `recv()` methods have zero logging overhead.
+> **Note**: HORUS uses a [zero-overhead IPC architecture](/concepts/zero-overhead-ipc) where introspection is separated from the hot path. The `send()` and `recv()` methods have zero logging overhead.
 
 ### The send() Method
 

content/docs/concepts/message-types.mdx

@@ -255,7 +255,7 @@ impl LogSummary for PointCloud {
 **Standard operation**:
 - `Topic::new("name")?` — zero-overhead, no logging, no `LogSummary` required
 - `Topic::new("name")?.with_logging()` — enables logging + metrics, requires `T: LogSummary`
-- Both use the same `send()`/`recv()` methods; there are no separate `send_logged()`/`recv_logged()` methods
+- Both use the same `send()`/`recv()` methods; logging behavior is configured at topic creation time
 - Implementing LogSummary is recommended so you can opt into logging when needed
 
 **When logging is active**:

content/docs/concepts/zero-overhead-ipc.mdx

@@ -6,7 +6,7 @@ order: 5
 
 # Zero-Overhead IPC Architecture
 
-HORUS v0.3+ introduces a **zero-overhead IPC architecture** that separates introspection from the hot path. This design ensures that `send()` and `recv()` have minimal latency regardless of whether monitoring tools are attached.
+HORUS uses a **zero-overhead IPC architecture** that separates introspection from the hot path. This design ensures that `send()` and `recv()` have minimal latency regardless of whether monitoring tools are attached.
 
 ## Key Takeaways
 
@@ -16,32 +16,9 @@ After reading this guide, you will understand:
 - How external tools monitor Topics without affecting performance
 - Performance characteristics of each backend
 
-## The Problem: Introspection Overhead
+## Architecture: Separated Introspection
 
-In traditional robotics frameworks, logging and timing are embedded in every message operation:
-
-```rust
-// OLD DESIGN (embedded introspection)
-pub fn send(&self, msg: T, ctx: &mut Option<&mut NodeInfo>) -> HorusResult<()> {
-    let start = Instant::now();           // +10-20ns
-
-    // Write to shared memory
-    self.backend.push(msg)?;
-
-    let elapsed = start.elapsed();        // +10-20ns
-    // Logging with hlog!
-        c.record_ipc_latency(elapsed);    // +50-100ns (logging)
-        c.log_pub(&self.name, &msg);      // +100-500ns (serialization)
-    }
-    Ok(())
-}
-```
-
-This adds **170-640ns of overhead** to every message, even when no one is monitoring!
-
-## The Solution: Separated Introspection
-
-HORUS separates introspection from the hot path:
+HORUS separates introspection from the hot path. Traditional frameworks embed logging and timing in every message operation, adding 170-640ns of overhead even when no one is monitoring. HORUS avoids this entirely:
 
 <MermaidDiagram
   chart={`%%{init: {'flowchart': {'padding': 20}}}%%
@@ -289,27 +266,6 @@ horus topic echo sensors
 horus monitor
 ```
 
-## Migrating from Old API
-
-If you're upgrading from HORUS v0.2.x, see the [Migration Guide](/development/migration-zero-overhead).
-
-**Quick summary:**
-
-```rust
-// OLD (v0.2.x) - ctx parameter required
-topic.send(msg)?;
-topic.recv()
-
-// NEW (v0.3+) - zero-overhead, infallible
-topic.send(msg);
-topic.recv()
-
-// NEW - opt-in introspection (configure once at creation)
-let topic = Topic::new("name")?.with_logging();
-topic.send(msg);    // logging happens automatically
-topic.recv()        // logging happens automatically
-```
-
 ## Design Rationale
 
 ### Why Separate Introspection?
@@ -350,6 +306,5 @@ This provides:
 ## Next Steps
 
 - [Topic Communication](/concepts/core-concepts-topic) - Full Topic API reference
-- [Migration Guide](/development/migration-zero-overhead) - Upgrading from v0.2.x
 - [Benchmarks](/performance/benchmarks) - Detailed performance data
 - [Backend Selection](/concepts/communication-transport) - Choosing the right backend

content/docs/development/error-handling.mdx

@@ -54,10 +54,12 @@ The main error type for all HORUS operations:
 | `AlreadyExists` | Resource already exists |
 | `ParseError` | Parsing errors |
 | `CommandFailed` | External command errors |
+| `Driver` | Driver-related errors |
 | `FeatureNotAvailable` | Feature not enabled |
 | `Unsupported` | Operation not supported on this platform |
-| `Internal` | Internal errors |
-| `Other` | Catch-all |
+| `Unsupported` | Operation not supported on this platform |
+| `Internal` | Internal errors with source location (`file`, `line`) |
+| `Contextual` | Error with preserved source chain |
 
 ## Creating Errors
 
@@ -98,6 +100,30 @@ let err = Error::PermissionDenied("/dev/ttyUSB0".to_string());
 let err = Error::AlreadyExists("Session 'main' already exists".to_string());
 ```
 
+### Internal Errors with Source Location
+
+Use the `horus_internal!()` macro to create internal errors that automatically capture file and line number:
+
+```rust
+use horus::prelude::*;
+
+// Captures file/line automatically
+return Err(horus_internal!("Unexpected state: {:?}", state));
+// Produces: Internal { message: "Unexpected state: ...", file: "src/foo.rs", line: 42 }
+```
+
+### Contextual Errors with Source Chain
+
+Use `.horus_context()` on Results to wrap errors with additional context while preserving the original error chain:
+
+```rust
+use horus::prelude::*;
+
+let config = load_file("robot.yaml")
+    .horus_context("Failed to load robot configuration")?;
+// If load_file fails, produces: Contextual { message: "Failed to...", source: <original error> }
+```
+
 ## Error Propagation
 
 ### Using the `?` Operator
@@ -129,7 +155,8 @@ fn load_robot_config(path: &str) -> Result<Config> {
 | `std::num::ParseIntError` | `Error::ParseError` |
 | `std::num::ParseFloatError` | `Error::ParseError` |
 | `uuid::Error` | `Error::Internal` |
-| `anyhow::Error` | `Error::Other` |
+| `std::sync::PoisonError` | `Error::Internal` |
+| `anyhow::Error` | `Error::Internal` |
 
 ## Error Checking
 
@@ -177,8 +204,8 @@ match result {
 // Good: Specific error with context
 return Err(Error::backend("IMU", "I2C read failed on register 0x3B"));
 
-// Avoid: Generic error
-return Err(Error::Other("error".to_string()));
+// Avoid: Internal without context
+return Err(horus_internal!("something went wrong"));
 ```
 
 ### 2. Add Context When Propagating