CI: fix Windows nmake env and Linux parallel-build race (Tests workflow)

[russimicro]

Contexto

Encontrado al revisar los checks de #24: ambos jobs de Tests ya fallaban en
main de forma independiente al PR de la rama web.

Windows — 'nmake' is not recognized

El paso "Build Harbour" ejecuta nmake en un cmd plano, sin el entorno de
desarrollo de MSVC cargado (INCLUDE/LIB/PATH para cl.exe, link.exe,
nmake.exe). run_tests.bat ya resuelve esto para su propio paso (localiza
VS con vswhere y llama a VsDevCmd.bat); este PR aplica la misma técnica
antes de invocar nmake.

Linux — link error en libhbmacro

make -j$(nproc) install de harbour/core fallaba de forma intermitente:

undefined reference to `hb_compExprReduceAT'
undefined reference to `hb_compExprAsLongNum'
... (más símbolos hb_compExpr*)
collect2: error: ld returned 1 exit status

Consistente con una carrera de orden en el Makefile de harbour/core bajo
build paralelo. Se cambia a make install secuencial (más lento, estable).

Alcance

Solo toca .github/workflows/tests.yml; no modifica ningún sample ni el
contrato de build existente.

🤖 Generado con Claude Code

[russimicro]

Estado tras 2 intentos — dejo esto documentado, sin más pushes

Windows — el primer intento (cargar VsDevCmd.bat antes de nmake)
reveló que harbour/core ya no trae win\msvc64\makefile.vc: ese árbol
win/ no existe en el repo actual. Cambié a su sistema de build real (GNU
Make, per doc/gmake.txt: HB_PLATFORM=win / HB_COMPILER=msvc64 +
win-make.exe del propio repo), pero ahora falla distinto:

win-make: *** No rule to make target 'install'.  Stop.

Rastreé la causa hasta config/dir.mk:

ifneq ($(HB_PLATFORM),)
ifneq ($(HB_COMPILER),)
...
first clean install::
	+$(DIR_RULE)

Los targets first/clean/install sólo se generan si HB_PLATFORM y
HB_COMPILER no están vacíos en el momento en que se evalúa ese
include — y a pesar de fijarlos con set antes de invocar win-make.exe,
al llegar a dir.mk aparecen vacíos. No tengo un entorno Windows+MSVC+GNU
Make disponible para seguir iterando con certeza (cada intento es un push
real + una corrida de CI), así que no voy a seguir adivinando a ciegas.

Linux — probé cambiar make -j$(nproc) install por make install
secuencial, asumiendo una carrera de compilación paralela (el síntoma es un
link error en libhbmacro: undefined reference to hb_compExprReduceAT,
hb_compExprAsLongNum, etc.). La hipótesis era incorrecta: el error es
idéntico sin -j. Esto sugiere que esas funciones (hb_compExprReduce* de
macrob.c) simplemente no se están compilando en esta configuración de
harbour/core — no es una carrera, es algo estructural en cómo esta
versión de core arma libhbmacro para el target install por defecto
(quizás requiera un flag/target adicional, o el macro-compilador se
construye de otra fuente que la esperada). No lo diagnostiqué más a fondo.

Conclusión: ambos fallos son preexistentes en main (no los causa este
PR ni el de la rama web #24) y apuntan a que el pineo de harbour/core que
usa este workflow (git clone --depth 1 a la rama por defecto, sin tag fija)
quedó desalineado con cómo ese repo se construye hoy. Quien conoce el build
de Harbour de memoria probablemente lo resuelve en minutos; prefiero
entregar el diagnóstico en vez de seguir empujando intentos a ciegas contra
CI ajeno. Dejo el branch fix/ci-tests-workflow tal cual quedó (con el
intento de Windows, que no funciona, y el de Linux, que tampoco) por si sirve
de punto de partida — con gusto lo reviso más si hay pistas adicionales del
lado de ustedes.

🤖 Generado con Claude Code