feat(install): preservar configuraciones existentes con ownership granular

[barbatdev]

Problema

install.sh es all-or-nothing y reemplaza archivos completos como karabiner.json, además de Ghostty, skhd, yabai, Starship y tmux. En un contexto OSS esos archivos pueden contener configuración del usuario; instalar Cortex no debe apropiarse de superficies ajenas.

Decisión

• Imports/includes: fragmento namespaced.
• Plugins/assets: instalar solo el asset propio.
• Archivo monolítico: preservar byte-for-byte; adopción o merge solo explícitos.
• Config inexistente: defaults únicamente con consentimiento.
• Uninstall: retirar solo paths/bloques propios.

Aplicación inicial

• Zsh: composición con source ya implementada.
• Karabiner: distribuir ~/.config/karabiner/assets/complex_modifications/cortex.json; no reemplazar karabiner.json.
• tmux: fragmento mediante source-file.
• Ghostty/skhd/yabai/Starship: definir estrategia aditiva o instalación opt-in.

Criterios de aceptación

• install.sh soporta componentes/selección explícita y default seguro.
• Manifest documenta paths owned y estrategia por herramienta.
• Configs preexistentes permanecen byte-for-byte intactas por defecto.
• Install/update/uninstall son idempotentes y reversibles.
• Karabiner instala asset namespaced sin reemplazar config principal.
• Doctor reporta installed/active/conflict por integración.
• Tests cubren config ausente, existente, symlink, directorio, opt-in y uninstall.
• Migración desde instalaciones all-or-nothing documentada con rollback.

Fuera de alcance

Implementar cambios en Cortex o cortex-dots; auto-merge opaco de JSON monolítico.

Relación

Relacionado con #31, que define la migración y source of truth de artefactos product-owned, pero no cubre la coexistencia OSS ni el ownership granular de configuraciones locales.