docs: record the compat.openssl windows gap as a TODO with its evidence

[Sunrisepeak]

compat.openssl windows support was attempted in #150 and did not land. That PR is now
a draft — as it stands it would be a windows regression: tests/examples/openssl goes
from a passing no-op main() to a failing build.

Rather than leave six rounds of CI archaeology in a closed branch, this writes down what
was learned so the next attempt starts where this one stopped.

Settled — not worth re-investigating

x64 windows path	only VC-WIN64A (Configurations/10-main.conf); the clang-cl configs are Windows-on-ARM
its build_scheme	VC-common → an NMAKE makefile, which GNU make cannot drive
host requirement 1	perl — xim:perl ships no windows build ("The Windows answer is Strawberry Perl")
host requirement 2	a VS C++ toolset, for nmake — xim:make is GNU make and linux-only

⚠️ Declaring xim:perl in a windows xpm block would fail resolution before install()
runs — the same trap compat.openssl already documents for xim:make on macosx.

Where it stops

vswhere finds the toolset correctly:

[bat] vspath=C:\Program Files\Microsoft Visual Studio\18\Enterprise

…and then running vcvars in any form takes the whole process chain down. Three shapes,
identical behaviour — stop at that line, no RESULT, no error:

• plain call "%VCVARS%" from the batch
• the build moved into a child cmd /c <inner.bat> (the outer script dies too)
• cmd /c ""%VCVARS%" & set" — the standard environment-dump technique

That no longer looks like a mistake in the descriptor, so the doc recommends running
perl Configure VC-WIN64A && nmake by hand on a windows machine inside the mcpp
sandbox before writing more code. All six rounds so far were blind CI iterations at ~10
minutes each.

Also replaced

The descriptor's old note said windows "requires prebuilt MSVC libs uploaded to
xlings-res". That is not the blocker, and leaving it would send the next person after
the wrong thing.

Five findings that apply to any install() hook

Not specific to openssl, and each cost a CI round to find:

1. log.error never reaches the job — failure is a bare E_INTERNAL: [openssl] failed:.
   The only surviving channel is a self-made log; validate.yml's dump step finds
   mcpp_*_build.log.
2. The xlings sandbox exposes a SUBSET of xmake's Lua API, and calling outside it kills
   the hook silently — no error, no traceback. Confirmed unavailable: os.curdir(),
   path.absolute().
3. os.exec can report success for a script that did nothing and wrote nothing.
4. The log must be created before anything that can fail, or CI prints "no install()
   build logs found" and you have zero information.
5. io.writefile does not translate line endings, while cmd's batch parsing assumes CRLF.

Blocked on this

mcpplibs.grpc (#151) is linux + macOS for this reason alone. grpc-m already carries its
windows compile/link flags; when this lands, restoring it is: grpc-m's windows CI leg,
pkgs/g/grpc.lua's windows xpm block, and tests/examples/grpc-module's windows gate.