feat(identity): switch social identity, all from the one backup

Adds pseudonymous, switchable social identities derived from the SAME root
seed via an account index (NostrKeyDerivation.deriveFromSeed(seed, account)).
HKDF is one-way so accounts are unlinkable to the Ğ1 key; account 0 is the
original identity, byte-for-byte unchanged (no rotation for current users),
and every account regenerates from the single seed — so switching adds
nothing to back up.

- SocialAccountStore: keystore-backed active account + max created.
- Per-identity stores (chats, profile, name cache) namespaced by account
  scope (account 0 = legacy keys, no migration) so identities never mix.
- switchSocialAccount() re-derives the identity, re-scopes the stores and
  restarts the inbox listener; RestartWidget rebuilds the tree to pick up
  the new social singletons. DB/inventory untouched.
- Profile 'Your identities' switcher: list, create, switch (with a note
  that messages/contacts are kept separate per identity). i18n en/es/pt/ast.

Tests: account-indexed derivation (legacy 0 unchanged, accounts distinct
yet deterministic, negatives rejected); SocialAccountStore; per-identity
store scope isolation. Resolves the flagged 'change identity' decision
(open-decisions §B).

Known: switching resets navigation to home (full tree rebuild).

docs/design/open-decisions.md

@@ -28,7 +28,7 @@ Estas fijan `schemaVersion = 1` y el arranque técnico:
 - **Integración Ğ1 (moneda libre):** niveles 1–2 (precio en Ğ1 + enlace a cartera Ğecko/Cesium²/Ğ1nkgo) en la capa social; nivel 3 (reusar la WoT de Ğ1 como fuente de confianza) como estudio aparte. → [g1-integration.md](g1-integration.md)
 - **Ofertas de banco colectivo** (publica la entidad, no la persona). → sharing-model §6
 - **Caducidad/revocación** de ofertas ya replicadas en relays. → sharing-model §6
-- **Cambiar de identidad social — IMPORTANTE, pendiente (feedback en dispositivo 2026-07-10).** Hoy la identidad Nostr se deriva una sola vez de la semilla raíz al arrancar (DI) y no hay forma de cambiarla. Se pidió poder hacerlo. Dos vías: **(A) identidad seudónima aparte** (recomendada, encaja con g1-integration.md §"peor caso": una clave Nostr distinta solo para lo social, manteniendo la semilla raíz para inventario/backup/Ğ1 intactos) o **(B) reinicio total** (nueva semilla raíz; se pierde la identidad y su recuperación). Implica **re-derivar la identidad al vuelo** (hoy se cachea en `SocialService` al iniciar) — probablemente con reinicio de la app o recreando `SocialService` + sesiones. Decidir modelo (seudónima vs reset), persistir la "semilla social activa" en el keystore, y que `SocialService.fromRootSeedHex` lea de ahí. → [[project-block2-spike]]
+- **Cambiar de identidad social — RESUELTO/IMPLEMENTADO (2026-07-10).** Se eligió una refinación de la vía (A) que **mantiene "backup UNA semilla"**: identidades seudónimas **derivadas de la misma semilla raíz con un índice de cuenta** (`NostrKeyDerivation.deriveFromSeed(seed, {account})`, HKDF one-way → no vinculables a Ğ1; **cuenta 0 = la identidad actual, byte-for-byte, sin rotar a nadie**). La cuenta activa se persiste en el keystore (`SocialAccountStore`), los stores por-identidad (chats/perfil/nombres) se **namespacian por cuenta** (cuenta 0 = claves legacy, sin migración), y `switchSocialAccount()` re-registra la porción social del DI y reinicia el inbox; la UI (perfil → "Tus identidades", crear/cambiar) aplica el cambio con un `RestartWidget` que reconstruye el árbol leyendo los singletons nuevos. La app NO toca la DB/inventario. Descartada la vía (B) reset total (perdía identidad+recuperación). → [[project-block2-spike]]
 
 ## C) Puede esperar (no bloquea nada ahora)