refactor(errors): adopt reportable error terminology

docs/src/errors.md

@@ -1,9 +1,9 @@
 # Errors
 
-Public Kaptan error enums derive the pure `KaptanError` implementation:
+Public reportable Kaptan error enums derive `KaptanError`:
 
 ```rust
-#[derive(Debug, kaptan_err_propagate::KaptanError)]
+#[derive(Debug, kaptan_err_reportable::KaptanError)]
 enum SensorError {
     #[kaptan_error(id = 12345)]
     TransferFault,
@@ -11,14 +11,14 @@ enum SensorError {
     UnexpectedIdentity(u8),
 }
 
-#[kaptan_err_propagate::propagate]
+#[kaptan_err_reportable::propagate]
 fn service_sensor() -> Result<(), SensorError> {
     read_sensor()?;
     Ok(())
 }
 ```
 
-The derive implements `core::error::Error`, `Display`, and `ErrorReport`. It
+The derive implements `core::error::Error`, `Display`, and `ReportableError`. It
 requires a nonzero explicit ID on every variant and retains no type, variant,
 or module string. `Display` renders the decimal ID. Renaming, moving, or
 reordering a Rust variant therefore does not change its receiver contract.
@@ -26,11 +26,11 @@ Missing and same-enum duplicate IDs are rejected by the derive. Reusing an ID
 across error enums generates the same reserved linker symbol and fails the
 final firmware build.
 
-`#[kaptan_err_propagate::propagate]` observes the ordinary `Result` produced
-by one terminal diagnostic boundary. If an `Err` leaves that function, the attribute
-makes one nonblocking admission attempt and returns the exact same `Err` to the
+`#[kaptan_err_reportable::propagate]` turns an annotated function into a
+reporting point. If a reportable `Err` leaves that function, the attribute makes
+one nonblocking admission attempt and returns the exact same `Err` to the
 caller. The record contains the final converted error ID and the compile-time
-`file:line` of that annotated boundary. This is where the `Err` enters
+`file:line` of that reporting point. This is where the `Err` enters
 diagnostics, not necessarily the line where a deeper callee originally
 constructed it. `?`, explicit returns, result aliases, and `From` conversion
 retain their normal Rust behavior. An error handled inside the function is
@@ -46,35 +46,35 @@ renaming, moving, or reordering an existing variant keeps its assigned ID.
 The example numbers above are illustrative and must be replaced with
 unallocated catalog values when used in production code.
 
-Only the terminal boundary is annotated. If nested functions are both
-annotated, each boundary makes its own report attempt; the ingress does not
+Only the intended reporting point is annotated. If nested functions are both
+annotated, each function makes its own report attempt; the ingress does not
 mark or mutate error values to deduplicate them. Expected validation,
 backpressure, retry, and untrusted-input results remain unannotated. In
 particular, transient SPI/I²C `Busy` and unavailable range measurements stay
 inside their service retry/idle paths. In contrast, every logging
 macro—including `kaptan_log::error!`—produces only
-`KAPTAN_LOG`. Error propagation is not a replacement for safety state,
+`KAPTAN_LOG`. Error reporting is not a replacement for safety state,
 actuator inhibit, or typed configuration results.
 
-`kaptan-err-propagate` owns error identity and its independent one-slot
-ingress. A pending record contains only the compact ID and a static reference
-to the propagation boundary's `file:line`. The MAVLink adapter copies that
+`kaptan-err-reportable` owns reportable-error identity and its independent
+one-slot ingress. A pending record contains only the compact ID and a static
+reference to the reporting point's `file:line`. The MAVLink adapter copies that
 location into its fixed field when constructing `KAPTAN_ERROR`. Producers never
 encode or transmit MAVLink themselves. Admission is bounded and lossy if a
-different typed error is already pending.
+different reportable error is already pending.
 
 ## What the receiver sees
 
 - Configuration writes receive authoritative structured failures through
   `KAPTAN_CONFIG_RESULT`: operation, lifecycle state, field IDs, validation
-  rule, and protocol error code. A terminal persistence failure also reports
-  the storage-only `CommitTransactionError::Store` boundary once as
+  rule, and protocol error code. A reportable persistence failure also emits
+  the storage-only `CommitTransactionError::Store` ID once as
   `KAPTAN_ERROR`; replaying the cached command result does not repeat the error
   or the flash operation.
-- Terminal typed `ErrorReport` faults reach the F722 MAVLink worker as a
+- Reported `ReportableError` values reach the F722 MAVLink worker as a
   `KAPTAN_ERROR`, subject to bounded transport admission. The payload is
   `{ error_id, raised_at[96] }`. `raised_at` is a zero-padded UTF-8
-  `file:line` prefix for the annotated propagation boundary.
+  `file:line` prefix for the reporting point.
   The message kind itself identifies an error; no level is duplicated in the
   payload. Dynamic human-readable context belongs in `KAPTAN_LOG`, while
   structured protocol failures remain in their owning response message.