Rename Castle Accounting extension to Libra

Full identifier rename: module path lnbits.extensions.castle →
lnbits.extensions.libra, DB ext_castle → ext_libra, URL prefix
/castle/ → /libra/, manifest id castle → libra, fava ledger slug
default castle-ledger → libra-ledger, Beancount source metadata
castle-api → libra-api and link prefixes castle-{entry,tx}- →
libra-{entry,tx}-, column castle_wallet_id → libra_wallet_id, all
Python/JS/HTML identifiers (castle_ext, CastleSettings,
castle_reference, castleWalletConfigured, etc.).

Display name "Castle Accounting" → "Libra" (the scales/balance
metaphor — fits double-entry bookkeeping).

No backward compat: production hosts will be force-updated. Old
castle-prefixed Beancount metadata in existing Fava ledgers is
historical; new entries use libra-* prefixes going forward.

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

MIGRATION_SQUASH_SUMMARY.md

@@ -1,11 +1,11 @@
-# Castle Migration Squash Summary
+# Libra Migration Squash Summary
 
 **Date:** November 10, 2025  
 **Action:** Squashed 16 incremental migrations into a single clean initial migration
 
 ## Overview
 
-The Castle extension had accumulated 16 migrations (m001-m016) during development. Since the software has not been released yet, we safely squashed all migrations into a single clean `m001_initial` migration.
+The Libra extension had accumulated 16 migrations (m001-m016) during development. Since the software has not been released yet, we safely squashed all migrations into a single clean `m001_initial` migration.
 
 ## Files Changed
 
@@ -16,37 +16,37 @@ The Castle extension had accumulated 16 migrations (m001-m016) during developmen
 
 The squashed migration creates **7 tables**:
 
-### 1. castle_accounts
+### 1. libra_accounts
 - Core chart of accounts with hierarchical Beancount-style names
 - Examples: "Assets:Bitcoin:Lightning", "Expenses:Food:Groceries"
 - User-specific accounts: "Assets:Receivable:User-af983632"
 - Includes comprehensive default account set (40+ accounts)
 
-### 2. castle_extension_settings
-- Castle-wide configuration
-- Stores castle_wallet_id for Lightning payments
+### 2. libra_extension_settings
+- Libra-wide configuration
+- Stores libra_wallet_id for Lightning payments
 
-### 3. castle_user_wallet_settings
+### 3. libra_user_wallet_settings
 - Per-user wallet configuration
 - Allows users to have separate wallet preferences
 
-### 4. castle_manual_payment_requests
-- User-submitted payment requests to Castle
+### 4. libra_manual_payment_requests
+- User-submitted payment requests to Libra
 - Reviewed by admins before processing
 - Includes notes field for additional context
 
-### 5. castle_balance_assertions
+### 5. libra_balance_assertions
 - Reconciliation and balance checking at specific dates
 - Multi-currency support (satoshis + fiat)
 - Tolerance checking for small discrepancies
 - Includes notes field for reconciliation comments
 
-### 6. castle_user_equity_status
+### 6. libra_user_equity_status
 - Manages equity contribution eligibility
 - Equity-eligible users can convert expenses to equity
 - Creates dynamic user-specific equity accounts: Equity:User-{user_id}
 
-### 7. castle_account_permissions
+### 7. libra_account_permissions
 - Granular access control for accounts
 - Permission types: read, submit_expense, manage
 - Supports hierarchical inheritance (parent permissions cascade)
@@ -56,10 +56,10 @@ The squashed migration creates **7 tables**:
 
 The following tables were **intentionally NOT included** in the final schema (they were dropped in m016):
 
-- **castle_journal_entries** - Journal entries now managed by Fava/Beancount (external source of truth)
-- **castle_entry_lines** - Entry lines now managed by Fava/Beancount
+- **libra_journal_entries** - Journal entries now managed by Fava/Beancount (external source of truth)
+- **libra_entry_lines** - Entry lines now managed by Fava/Beancount
 
-Castle now uses Fava as the single source of truth for accounting data. Journal operations:
+Libra now uses Fava as the single source of truth for accounting data. Journal operations:
 - **Write:** Submit to Fava via FavaClient.add_entry()
 - **Read:** Query Fava via FavaClient.get_entries()
 
@@ -106,7 +106,7 @@ For reference, the original migration sequence (preserved in migrations_old.py.b
 For new installations:
 
 ```bash
-# Castle's migration system will run m001_initial automatically
+# Libra's migration system will run m001_initial automatically
 # No manual intervention needed
 ```
 
@@ -174,20 +174,20 @@ After squashing, verify the migration works:
 
 ```bash
 # 1. Backup existing database (if any)
-cp castle.sqlite3 castle.sqlite3.backup
+cp libra.sqlite3 libra.sqlite3.backup
 
 # 2. Drop and recreate database to test fresh install
-rm castle.sqlite3
+rm libra.sqlite3
 
 # 3. Start LNbits - migration should run automatically
 poetry run lnbits
 
 # 4. Verify tables created
-sqlite3 castle.sqlite3 ".tables"
-# Should show: castle_accounts, castle_extension_settings, etc.
+sqlite3 libra.sqlite3 ".tables"
+# Should show: libra_accounts, libra_extension_settings, etc.
 
 # 5. Verify default accounts
-sqlite3 castle.sqlite3 "SELECT COUNT(*) FROM castle_accounts;"
+sqlite3 libra.sqlite3 "SELECT COUNT(*) FROM libra_accounts;"
 # Should show: 40 (default accounts)
 ```
 
@@ -200,12 +200,12 @@ If issues are discovered:
 cp migrations_old.py.bak migrations.py
 
 # Restore database
-cp castle.sqlite3.backup castle.sqlite3
+cp libra.sqlite3.backup libra.sqlite3
 ```
 
 ## Notes
 
-- This squash is safe because Castle has not been released yet
+- This squash is safe because Libra has not been released yet
 - No existing production databases need migration
 - Historical migrations preserved in migrations_old.py.bak
 - All functionality preserved in final schema