refactor(errors): adopt reportable error terminology

docs/src/architecture.md

@@ -80,16 +80,16 @@ The build watches every fragment and generates one `message::kaptan` module;
 fragments are never separately generated Rust modules. `kaptan-log` itself has
 no MAVLink, platform, time, allocation, or filesystem dependency; its sole
 configuration coupling is compile-time enum metadata for `LevelFilter`.
-`kaptan-err-propagate` independently owns explicitly assigned typed-error identity,
-function-boundary propagation, and a bounded nonblocking ingress; it has
+`kaptan-err-reportable` independently owns explicitly assigned reportable-error
+identity and a bounded nonblocking ingress; it has
 no logging, MAVLink, platform, filesystem, or clock dependency. Event creation
 is independent from sink filtering, allowing a future blackbox and MAVLink to
-select different policies. The platform drains typed errors before its bounded
+select different policies. The platform drains reportable errors before its bounded
 critical and best-effort log queues and removes a pending record only after TX
 admission. `KAPTAN_LOG` carries one conventional level plus one bounded text
 field; `KAPTAN_ERROR` carries an explicitly assigned 16-bit ID and the bounded
-`file:line` of the reporting boundary. Its
-message kind already identifies a typed firmware error. Heartbeat and safety
+`file:line` of the reporting point. Its
+message kind already identifies a reportable firmware error. Heartbeat and safety
 telemetry remain separate from diagnostics.
 
 See [Configuration](configuration.md) for the deployment matrix and GCS transaction