Export the four names openkal.exec calls, and refuse for one reason

Two failures, both from the conformance run this change made selective.

⚠️ `VirtualAlloc', `VirtualProtect', `VirtualFree' and
`FlushInstructionCache' were declared in src/win32.h and exported by no
`.def'. This package's own check says so in as many words --- "declared
in src/win32.h and exported by no .def" --- and it is the check that
exists because an import library here is a list of names rather than
code, so a name absent from the list is a link that finds nothing on a
machine without a vendor SDK.

⚠️⚠️ AND `kal_timeout_read' UPON THE STANDARD INPUT HAD TWO REFUSALS
WHERE THE INTERFACE HAS ONE. An earlier form answered a null or invalid
handle with `kal_err_invalid' and a valid non-socket with
`kal_err_not_supported'; a run whose standard input is not attached has a
handle of zero, so both bounded reads in the suite were reported as not
holding.

⭐ The early return was answering a DIFFERENT QUESTION. "Is this handle
valid" is what the unbounded operation answers. What this interface
answers is whether this implementation can bound an operation upon this
resource, and timeout.h sanctions exactly one refusal for that: "AN
IMPLEMENTATION MAY PROVIDE THIS FOR SOME OF ITS RESOURCES AND NOT OTHERS,
and reports kal_err_not_supported for the rest." A handle that is not a
socket is one of the rest, and zero is not a socket.

The name/export reading is also performed here before pushing, so that a
round is not spent discovering a fifth name: 49 declared, 55 exported,
none missing.

Author: speak-agent

port/kernel32.def

@@ -10,6 +10,7 @@ CreatePipe
 CreateProcessW
 CreateThread
 FlushFileBuffers
+FlushInstructionCache
 FreeEnvironmentStringsW
 GetCommandLineW
 GetConsoleMode
@@ -41,6 +42,9 @@ SetHandleInformation
 Sleep
 SwitchToThread
 TerminateProcess
+VirtualAlloc
+VirtualFree
+VirtualProtect
 WaitForSingleObject
 WideCharToMultiByte
 WriteFile

src/timeout.cpp

@@ -70,8 +70,21 @@ int await(SOCKET s, short events, kal_u64 ns) {
 }
 
 int await_stream(kal_stream s, short events, kal_u64 ns) {
+    // ⚠️ ONE REASON TO REFUSE, AND NOT TWO. An earlier form answered a null or
+    // invalid handle with `kal_err_invalid' and a valid non-socket with
+    // `kal_err_not_supported', and the conformance suite reported both bounded
+    // reads of the standard input as not holding: a run whose standard input is
+    // not attached has a handle of zero, and the suite's list of admissible
+    // answers is the interface's --- success, an expiry, or a refusal.
+    //
+    // ⭐ The early return was answering a DIFFERENT QUESTION. "Is this handle
+    // valid" is what the unbounded operation answers; what this interface
+    // answers is whether this implementation can bound an operation upon this
+    // resource, and the header sanctions exactly one refusal for that: "AN
+    // IMPLEMENTATION MAY PROVIDE THIS FOR SOME OF ITS RESOURCES AND NOT OTHERS,
+    // and reports kal_err_not_supported for the rest." A handle that is not a
+    // socket is one of the rest, and zero is not a socket.
     const SOCKET raw = static_cast<SOCKET>(s.h);
-    if (raw == 0 || raw == INVALID_SOCKET) return kal_err_invalid;
     if (!is_socket(raw)) return kal_err_not_supported;
     return await(raw, events, ns);
 }