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/architecture-map/04-llm-formatting-mcp/cloud-providers-stubs.md

@@ -9,11 +9,11 @@ last_verified: 2026/05/09
 
 > **Where you are:** [Architecture map](../README.md) → [LLM, Formatting, MCP](README.md) → Cloud providers
 
-**Plain English summary.** `magnotia-cloud-providers` is reserved scaffolding for future bring-your-own-key cloud STT integrations. Today, only an in-memory API key store is wired. No HTTP transports, no OpenAI client, no Anthropic client, no STT calls. The crate exists so the workspace shape is right when those features land.
+**Plain English summary.** `lumotia-cloud-providers` is reserved scaffolding for future bring-your-own-key cloud STT integrations. Today, only an in-memory API key store is wired. No HTTP transports, no OpenAI client, no Anthropic client, no STT calls. The crate exists so the workspace shape is right when those features land.
 
 ## At a glance
 
-- Crate: `magnotia-cloud-providers`
+- Crate: `lumotia-cloud-providers`
 - Paths:
   - `crates/cloud-providers/Cargo.toml` — 9 lines
   - `crates/cloud-providers/src/lib.rs` — 3 lines (re-exports)
@@ -23,7 +23,7 @@ last_verified: 2026/05/09
   - `pub fn store_api_key(provider: &str, key: &str)` (`crates/cloud-providers/src/keystore.rs:15`)
   - `pub fn retrieve_api_key(provider: &str) -> Option<String>` (`crates/cloud-providers/src/keystore.rs:27`)
   - Both re-exported at crate root via `pub use keystore::{retrieve_api_key, store_api_key}` (`crates/cloud-providers/src/lib.rs:3`).
-- External deps that matter: only `magnotia-core` (declared, not currently used by the keystore — reserved for the future provider implementations). `std::env` for the env-var fallback.
+- External deps that matter: only `lumotia-core` (declared, not currently used by the keystore — reserved for the future provider implementations). `std::env` for the env-var fallback.
 - Tauri command that calls this (slice 2, best guess): no current call sites observed in `src-tauri/src`. The intended call sites are `commands::cloud::store_api_key_cmd` / `_retrieve` for any future provider configuration UI, but neither exists today.
 
 ## What's in here
@@ -73,7 +73,7 @@ A static atomic counter generates unique provider names per test so concurrent r
 
 ### What is *not* here
 
-The crate's name and Cargo description ("BYOK cloud STT provider stubs and API key storage for Magnotia") imply a much larger surface. None of this exists yet:
+The crate's name and Cargo description ("BYOK cloud STT provider stubs and API key storage for Lumotia") imply a much larger surface. None of this exists yet:
 
 - **No HTTP client.** No `reqwest` dependency, no transport layer.
 - **No OpenAI / Anthropic / Whisper API clients.** No request/response types, no streaming code.
@@ -103,7 +103,7 @@ Intended (future):
 Tauri command (commands::cloud::transcribe_cmd, hypothetical)
   → retrieve_api_key("openai") → Option<String>
   → reqwest POST to provider transcribe endpoint
-  → parse provider response → magnotia_core::types::Segment list
+  → parse provider response → lumotia_core::types::Segment list
   → return to caller, who feeds it into the formatting pipeline
 ```
 
@@ -115,7 +115,7 @@ The formatting pipeline does not need to change to consume cloud-transcribed seg
 - **API keys vanish on restart.** The TODO is explicit. Until `keyring` integration lands, every cloud-provider feature using these helpers will need to re-prompt the user on every startup or break for headless deployments. Acceptable for a stub; not acceptable for a shipped feature.
 - **Env-var fallback is `MAGNOTIA_API_KEY_<PROVIDER>`.** Provider names are uppercased in the env-key construction. A provider name with hyphens or underscores will produce a slightly weird-looking env var; not broken, but worth knowing. `provider = "open-ai"` becomes `MAGNOTIA_API_KEY_OPEN-AI`.
 - **No threading concerns beyond the mutex.** `Mutex<HashMap>` is fine here because keys are written rarely and read on the path of a network call that dwarfs any contention. The previous note in the doc-comment about "undefined behaviour of mutating process environment variables from arbitrary threads" refers to a discarded design that used `std::env::set_var` — that approach is unsound under the modern Rust memory model. The current in-memory map is the safe replacement.
-- **`magnotia-core` dependency is declared but not currently used in this file.** It is reserved for when the providers themselves arrive (they will likely consume `Segment` and tuning helpers).
+- **`lumotia-core` dependency is declared but not currently used in this file.** It is reserved for when the providers themselves arrive (they will likely consume `Segment` and tuning helpers).
 - **Security of the in-memory map is process-lifetime only.** A core dump or a memory-inspection attack reveals the keys. The `keyring`-backed replacement will inherit OS-level protections; until then the threat model is "user trusts their own machine".
 - **No call sites in the Tauri binary today.** Searching `src-tauri/src` for `cloud_providers`, `store_api_key`, or `retrieve_api_key` returns nothing. The crate is purely speculative scaffolding right now. Confirmed: the only references in the workspace are within the crate itself.