fix: añadir .gitattributes con eol=lf y troubleshooting CRLF

El issue #1 (WSL errors in deploy.sh) ocurre porque deploy.sh llega
con saltos de línea CRLF al usuario, probablemente al descargarlo
desde un navegador en Windows o editarlo con bloc de notas.

El bash interpreta '\r' final de línea como parte del comando, lo que
rompe 'set -e' (visto como 'set: usage:') y provoca $'\r': command not
found en cada línea ejecutada.

Cambios:
- .gitattributes: fuerza eol=lf en clones (raíz del problema)
- README.md: documenta el workaround 'sed -i s/\r$// deploy.sh' para
  archivos ya descargados con CRLF, y explica cuándo ocurre

Probado: con .gitattributes, 'git clone' desde Windows produce archivos
en LF automáticamente; sin él, 'core.autocrlf=true' los contaminaba.

Closes #1

README.md

@@ -108,6 +108,22 @@ pero no es necesaria. Con 8 GB de RAM ya puedes usar llama3.2:3b.
 Claro. Los modelos de 7-14B son útiles para redacción, traducción,
 resumen, código, SEO y mucho más. Cuanta más RAM, mejor calidad.
 
+## Troubleshooting
+
+### `set: usage:` o `$'\r': command not found` al ejecutar `deploy.sh` (WSL / Git Bash)
+
+El archivo llegó con saltos de línea de Windows (CRLF). El repositorio
+incluye `.gitattributes` para que esto no pase al clonarlo, pero si ya
+lo tienes descargado con CRLF, normalo a Unix:
+
+```bash
+sed -i 's/\r$//' deploy.sh && ./deploy.sh
+```
+
+Esto ocurre sobre todo cuando se descarga el archivo desde un navegador
+en Windows o se edita con el bloc de notas. Con `git clone` desde
+cualquier sistema queda en LF automáticamente.
+
 ## Licencia
 
 MIT. Usa, modifica y comparte libremente.