agent: lumotia-rebrand — docs, scripts, root config, residuals

Phase 9 of the rebrand cascade. Sweep covers everything the Phase 8
frontend pass deliberately skipped: docs/, root markdown, scripts,
Cargo.toml descriptions, code comments that survived earlier
word-boundary sed, plus a handful of identifiers caught on the final
verify pass.

transcription-app changes:
- README.md, HANDOVER.md, KNOWN-ISSUES.md, run.sh — magnotia/Magnotia
  -> lumotia/Lumotia.
- docs/ — sweep across all subdirs except docs/handovers/ (preserved
  as immutable audit trail). Includes architecture-map references
  to magnotia_core::*, magnotia_storage::*, etc. now pointing at
  lumotia_*; dev-setup.md tracing output examples (lumotia_startup
  target); brief/ + superpowers/ + issues/ + whisper-ecosystem/ +
  audit/.
- Cargo.toml descriptions on 9 crates (core, audio, cloud-providers,
  hotkey, llm, mcp, plus referenced others).
- crates/core/src/{error,hardware,recommendation,paths}.rs +
  crates/audio/src/wav.rs + crates/llm/src/model_manager.rs +
  crates/cloud-providers/src/keystore.rs + crates/mcp/src/lib.rs —
  doc comments and a model-manager user-agent string.
- Caught on final pass: BroadcastChannel("magnotia_task_sync") -> ...
  ("lumotia_task_sync"); magnotia_locale i18n localStorage key
  renamed + migration shim added; CSS keyframe names
  magnotiaPulse / magnotiaBar / magnotiaFade renamed in the design-
  system kit; magnotia_viewer_item / magnotia_viewer_mode handoff
  keys renamed in HistoryPage + viewer/+page.svelte; src/assets/
  wordmark.svg text.
- src-tauri/src/lib.rs comment cleanup ("magnotia era" was sed'd
  to "lumotia era" earlier — restored).

Preserved (intentional):
- crates/core/src/paths.rs — keeps "magnotia" / "Magnotia" / ".magnotia"
  legacy detection strings in legacy_and_target_paths() so the
  migration shim can still find user data from the magnotia era.
- src/lib/stores/{page,focusTimer}.svelte.ts + src/lib/i18n/index.ts
  — migration call sites reference the legacy magnotia keys
  deliberately.
- docs/handovers/ — historical audit trail.

cargo build --workspace passes. npm run check: 0 errors / 0 warnings
(3958 files). cargo test --workspace: 339 pass / 0 fail.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

docs/superpowers/plans/2026-05-12-area-a-storage-errors-survey.md

@@ -2,7 +2,7 @@
 name: Area A — storage error inventory and proposed taxonomy
 type: survey
 tags: [engine, residuals, area-a, storage, errors, survey]
-description: Pre-migration survey for engine-slop residuals Area A. Catalogues every MagnotiaError::StorageError construction site in the storage crate, groups by failure mode, proposes a typed magnotia_storage::Error enum with a serializable MagnotiaError::Storage variant on top, and flags ambiguities + migration risks. No code changes yet.
+description: Pre-migration survey for engine-slop residuals Area A. Catalogues every MagnotiaError::StorageError construction site in the storage crate, groups by failure mode, proposes a typed lumotia_storage::Error enum with a serializable MagnotiaError::Storage variant on top, and flags ambiguities + migration risks. No code changes yet.
 status: draft
 ---
 
@@ -12,7 +12,7 @@ There is no `StorageError` enum to extend. The storage crate has zero local erro
 
 The Tauri command layer stringifies every error before crossing into the frontend (`Result<T, String>` everywhere via `.map_err(|e| e.to_string())?`), so `MagnotiaError`'s `Serialize` impl is presently unused at the FE/BE boundary. Area E is where that ossifies; Area A's job is to give **backend** code something to branch on — not to fix the frontend.
 
-Proposed: introduce a new `magnotia_storage::Error` enum in the storage crate, replace the `String` tail of `MagnotiaError::StorageError(String)` with a structured `MagnotiaError::Storage { kind, operation, detail }` variant, and wire the conversion through a `From<storage::Error> for MagnotiaError` impl that flattens the structured error into a serde-friendly shape. Backend code can pattern-match on `storage::Error`; the frontend keeps receiving (slightly nicer) strings until Area E.
+Proposed: introduce a new `lumotia_storage::Error` enum in the storage crate, replace the `String` tail of `MagnotiaError::StorageError(String)` with a structured `MagnotiaError::Storage { kind, operation, detail }` variant, and wire the conversion through a `From<storage::Error> for MagnotiaError` impl that flattens the structured error into a serde-friendly shape. Backend code can pattern-match on `storage::Error`; the frontend keeps receiving (slightly nicer) strings until Area E.
 
 ## Inventory
 
@@ -28,7 +28,7 @@ Proposed: introduce a new `magnotia_storage::Error` enum in the storage crate, r
 
 ### Storage crate context
 
-- Uses `magnotia_core::error::{MagnotiaError, Result}` directly — no local error type.
+- Uses `lumotia_core::error::{MagnotiaError, Result}` directly — no local error type.
 - No `From<sqlx::Error>` impl exists, which is why every sqlx call has an explicit `.map_err(...)`.
 - `From<std::io::Error> for MagnotiaError` does exist (in `crates/core/src/error.rs`), so directory-creation paths use `?` cleanly.
 
@@ -114,7 +114,7 @@ This is **not a sqlx failure**. It's an integrity check we perform manually befo
 
 ### Where it lives
 
-**Option A (recommended): new `magnotia_storage::Error` enum in the storage crate.**
+**Option A (recommended): new `lumotia_storage::Error` enum in the storage crate.**
 
 ```rust
 // crates/storage/src/error.rs
@@ -189,7 +189,7 @@ pub type Result<T> = std::result::Result<T, Error>;
 **Why option A:**
 
 - The taxonomy lives where the failures originate. Storage owns its own error vocabulary.
-- The storage crate can be tested in isolation without `magnotia_core` understanding its internals.
+- The storage crate can be tested in isolation without `lumotia_core` understanding its internals.
 - `From<storage::Error> for MagnotiaError` keeps propagation automatic via `?`.
 - Sets up Area E to selectively expose storage-error kinds to the frontend without a second migration of call sites.
 
@@ -211,7 +211,7 @@ pub enum MagnotiaError {
 ```
 
 - Less ceremony, one file changes.
-- But couples the storage taxonomy into `magnotia_core`, which is a leaky abstraction.
+- But couples the storage taxonomy into `lumotia_core`, which is a leaky abstraction.
 - Harder to extend later when, say, we add a vocabulary crate (per D1 in the architecture spec) that also wants typed errors — every crate ends up dumping its enum into `MagnotiaError`.
 
 ### How it crosses the MagnotiaError boundary
@@ -244,14 +244,14 @@ pub enum StorageKind {
     InvalidReference,
 }
 
-impl From<magnotia_storage::Error> for MagnotiaError {
-    fn from(e: magnotia_storage::Error) -> Self {
+impl From<lumotia_storage::Error> for MagnotiaError {
+    fn from(e: lumotia_storage::Error) -> Self {
         let kind = match &e {
-            magnotia_storage::Error::DatabaseOpen { .. } => StorageKind::DatabaseOpen,
-            magnotia_storage::Error::Migration { .. } => StorageKind::Migration,
-            magnotia_storage::Error::Query { .. } => StorageKind::Query,
-            magnotia_storage::Error::NotFound { .. } => StorageKind::NotFound,
-            magnotia_storage::Error::InvalidReference { .. } => StorageKind::InvalidReference,
+            lumotia_storage::Error::DatabaseOpen { .. } => StorageKind::DatabaseOpen,
+            lumotia_storage::Error::Migration { .. } => StorageKind::Migration,
+            lumotia_storage::Error::Query { .. } => StorageKind::Query,
+            lumotia_storage::Error::NotFound { .. } => StorageKind::NotFound,
+            lumotia_storage::Error::InvalidReference { .. } => StorageKind::InvalidReference,
         };
         let operation = e.operation_label().into_owned();
         let detail = e.to_string();
@@ -260,17 +260,17 @@ impl From<magnotia_storage::Error> for MagnotiaError {
 }
 ```
 
-`operation_label()` is a helper on `storage::Error` returning a `Cow<'static, str>` from the inner enum data. Backend code that wants programmatic recovery downcasts (or rather, the storage call signatures return `Result<_, magnotia_storage::Error>` directly — only public Tauri-facing wrappers eat the `From` conversion).
+`operation_label()` is a helper on `storage::Error` returning a `Cow<'static, str>` from the inner enum data. Backend code that wants programmatic recovery downcasts (or rather, the storage call signatures return `Result<_, lumotia_storage::Error>` directly — only public Tauri-facing wrappers eat the `From` conversion).
 
 ### Function-signature decision
 
-The storage crate has 70+ public functions returning `magnotia_core::Result<...>`. Two options:
+The storage crate has 70+ public functions returning `lumotia_core::Result<...>`. Two options:
 
-1. **Change all to `magnotia_storage::Result<...>`** and let `?` in callers do the From conversion. Pros: backend code that wants typed errors gets them. Cons: ~70 signatures to touch, and any backend code that wanted the structured error has to import `magnotia_storage::Error`.
+1. **Change all to `lumotia_storage::Result<...>`** and let `?` in callers do the From conversion. Pros: backend code that wants typed errors gets them. Cons: ~70 signatures to touch, and any backend code that wanted the structured error has to import `lumotia_storage::Error`.
 
-2. **Keep public signatures as `magnotia_core::Result<...>`, do the conversion at the storage-crate boundary** via an internal `Result<T> = std::result::Result<T, magnotia_storage::Error>` for internal helpers. Public functions then end with `? `(or `.map_err(Into::into))`. Pros: caller signatures unchanged. Cons: callers wanting to pattern-match on storage failure type have nothing to match against (back to square one).
+2. **Keep public signatures as `lumotia_core::Result<...>`, do the conversion at the storage-crate boundary** via an internal `Result<T> = std::result::Result<T, lumotia_storage::Error>` for internal helpers. Public functions then end with `? `(or `.map_err(Into::into))`. Pros: caller signatures unchanged. Cons: callers wanting to pattern-match on storage failure type have nothing to match against (back to square one).
 
-**Recommended: option 1.** It's the more honest signature. ~70 public functions get changed, but it's mechanical: `Result<T>` → `magnotia_storage::Result<T>` and the body's `MagnotiaError::StorageError(format!(...))` is what we're replacing anyway. Callers (Tauri commands) that currently `.map_err(|e| e.to_string())?` keep working because the storage error From-converts into MagnotiaError, which is what Display'd into the string they're already producing.
+**Recommended: option 1.** It's the more honest signature. ~70 public functions get changed, but it's mechanical: `Result<T>` → `lumotia_storage::Result<T>` and the body's `MagnotiaError::StorageError(format!(...))` is what we're replacing anyway. Callers (Tauri commands) that currently `.map_err(|e| e.to_string())?` keep working because the storage error From-converts into MagnotiaError, which is what Display'd into the string they're already producing.
 
 This also means **Area E later only has to delete `.map_err(|e| e.to_string())?` and change return types** to receive structured errors — no second pass over the storage call sites.
 
@@ -333,7 +333,7 @@ The 64 sites in Bucket 3. Operation labels match the current message stem in sna
    - Derive Serialize and `#[serde(skip)]` the `sqlx::Error` source. Loses source detail in serialised form.
    - Custom Serialize impl that stringifies the source.
    - Don't derive Serialize — flatten only at the `MagnotiaError` boundary as proposed above.
-   **Recommendation:** the third. Keeps the storage crate's API surface backend-only; serialisation concerns live in `magnotia_core`. Already reflected in the proposal.
+   **Recommendation:** the third. Keeps the storage crate's API surface backend-only; serialisation concerns live in `lumotia_core`. Already reflected in the proposal.
 
 6. **Public re-exports from storage crate.** Need to decide: do we re-export `Error`, `Result`, `OpenOp`, `MigrationStep`, `Entity`, `StorageKind` (or its storage-side equivalent) from `crates/storage/src/lib.rs`? Yes — backend code (Tauri commands, future test code) will want to pattern-match. Suggest a `pub mod error;` + `pub use error::{Error, Result, OpenOp, MigrationStep, Entity};` block.
 
@@ -347,7 +347,7 @@ The 64 sites in Bucket 3. Operation labels match the current message stem in sna
 
 ### Compile-time gotchas
 
-- **`?` operator semantics depend on which `Result` is in scope.** If function signature returns `magnotia_core::Result<T>` and body uses `magnotia_storage::Result<T>` internally, every helper boundary needs an explicit `Into::into` or a `?` cascade with `From` plumbed. Doable but easy to miss — recommend going function-by-function, not file-by-file.
+- **`?` operator semantics depend on which `Result` is in scope.** If function signature returns `lumotia_core::Result<T>` and body uses `lumotia_storage::Result<T>` internally, every helper boundary needs an explicit `Into::into` or a `?` cascade with `From` plumbed. Doable but easy to miss — recommend going function-by-function, not file-by-file.
 
 - **Test ergonomics.** Storage crate tests at `crates/storage/src/migrations.rs:1027+` currently match on `MagnotiaError::StorageError` patterns. They'll need updating to match on `storage::Error::Migration { step: MigrationStep::Apply, .. }` style. Roughly 5–10 test assertions, all bounded to that file.
 
@@ -356,7 +356,7 @@ The 64 sites in Bucket 3. Operation labels match the current message stem in sna
 - **Do not retitle error messages.** Goal is to preserve the current Display output verbatim where possible, with the operation label carrying the same information as the current message stem. Wording changes belong in a separate pass.
 
 - **Do not change `MagnotiaError::StorageError(String)` → `MagnotiaError::Storage { ... }` in one PR alongside the storage-crate work.** Two commits:
-  1. Add `magnotia_storage::Error`, `From<storage::Error> for MagnotiaError`, keep the old `StorageError(String)` variant temporarily as a no-op (compile-only).
+  1. Add `lumotia_storage::Error`, `From<storage::Error> for MagnotiaError`, keep the old `StorageError(String)` variant temporarily as a no-op (compile-only).
   2. Remove the old `StorageError(String)` variant; all consumers now go through `Storage { ... }`.
 
   Two commits means we can verify the type-system migration is sound before deleting the safety net.
@@ -369,10 +369,10 @@ Once the migration lands:
 
 ```
 cargo fmt --all -- --check
-cargo check -p magnotia-storage
-cargo check -p magnotia-core
+cargo check -p lumotia-storage
+cargo check -p lumotia-core
 cargo check --workspace --all-targets
-cargo test -p magnotia-storage
+cargo test -p lumotia-storage
 cargo test --workspace --lib
 rg 'StorageError\(' crates/ src-tauri/src/   # must be zero
 rg 'Other\(String\)' crates/ src-tauri/src/  # must remain zero