feat(zsh): separar ownership de dotfiles y Cortex

[barbatdev]

Resumen

Separa el profile en un bootstrap mínimo de zshrc y un entrypoint propio y estable de dotfiles. El bootstrap carga dotfiles primero y deja la integración de Cortex para el final.

Ownership

• Cortex mantiene el ownership de sus variables core y de su fragmento shell.
• Dotfiles usa el namespace CORTEX_DOTFILES_*.
• Este cambio no modifica Cortex ni reactiva cortex-dots.

Tolerancia

El bootstrap sigue intentando la siguiente capa cuando un fragmento está ausente, retorna nonzero o tiene sintaxis rota.

Instalación

install.sh hace backup del destino existente y crea el symlink estable en ~/.config/cortex-dotfiles/shell/cortex-dotfiles.zsh.

Tests

• ./scripts/check-cortex-shell-integration.sh
• ./scripts/check-agent-state.sh
• ./install.sh --check

Los tres checks pasan. install.sh --check reporta únicamente warnings esperados porque este worktree no es el checkout actualmente instalado.

Vínculos

• Contexto: fix(zsh): la función cortex() shadowea el binario del CLI de cortex #35 (comment)
• Coordinación: https://github.com/barbatdev/cortex/issues/1259

Revisión

Revisá primero el bootstrap en zsh/zshrc, después el entrypoint zsh/cortex-dotfiles.zsh y finalmente los escenarios de tolerancia del check de integración.

[barbatdev]

Hice un QA post-merge sobre 73e8cb7. Los smoke checks declarados pasan, pero las pruebas dirigidas encontraron algunos follow-ups que conviene resolver desde este repo antes de considerar estable el contrato OSS.

Prioridad alta

1. local/env.zsh se crea con permisos 0644 (install.sh:625-632).

   • Reproducido con umask 022: queda legible por grupo y otros usuarios.
   • Como el archivo está destinado a API keys y endpoints privados, debería crearse bajo umask 077 y quedar en 0600.

2. El entrypoint puede apuntarse a código arbitrario mediante ambiente heredado (zsh/zshrc:3-18).

   • CORTEX_DOTFILES_SHELL_ENTRYPOINT acepta cualquier archivo legible y lo ejecuta al iniciar Zsh.
   • Conviene usar la ruta estable por defecto y permitir overrides solamente mediante un opt-in explícito y validado.

3. Un directorio existente en el destino deja una instalación falsa (install.sh:429-439,494-503).

   • Reproducido: ln -sfn crea el symlink dentro del directorio, mientras el instalador informa éxito.
   • El destino debería rechazarse claramente o moverse después del backup, verificando al final que el path exacto sea el symlink esperado.

4. Los symlinks anteriores se reemplazan sin conservar su referencia (install.sh:429-439,459-460,497,502-503).

   • Aplica también a symlinks dangling.
   • El target anterior no se elimina, pero se pierde el enlace original.
   • Conviene respaldarlo con semántica cp -P o registrar su target antes del reemplazo.

Prioridad media

• El source repetido duplica entradas de PATH (zsh/cortex-dotfiles.zsh:18-19). Dos cargas aumentaron el PATH de 7 a 12 componentes y duplicaron $HOME/.local/bin. No se acumularon aliases, funciones ni hooks.
• README.md:98-110 debería limitarse al ownership observable desde dotfiles y referenciar cortex#1259 para el contrato del core, en vez de declarar unilateralmente ownership del otro repo.

Cobertura sugerida

Agregar regresiones para:

• destino previo como archivo, symlink válido, symlink dangling y directorio;
• permisos privados de local/env.zsh;
• override heredado del entrypoint;
• doble source y estabilidad de PATH;
• ejecución equivalente en macOS.

El contrato general del PR sigue siendo el correcto: CORTEX_DOTFILES_* para este proyecto, dotfiles primero, Cortex al final y sin volver a definir cortex. Estos hallazgos son de hardening y resiliencia de la implementación.