[Sunrisepeak]

Fixes #53.

kal_net_close, kal_net_close_listener and kal_datagram_close closed the descriptor and then retired the handle. The kernel gives a closed number to the next open in any context, so a file or a connection another context opened between the two took the number with the generation the socket's handle still had, and the retire then made its handle stale. kal_fs_stream and kal_net_stream answered a stale handle with zero, standard input.

• Every release is okl::release (src/handle.h), which retires and then closes; the three closes of openkal.net and openkal.datagram and the two of openkal.fs call it.
• The generation is advanced by a compare-and-exchange from the value the handle carries, so one release closes and a second release of the same word closes nothing. It is read through the atomic operations (the report's second point).
• A stream enquiry answers a handle that names no live descriptor with a word no descriptor has, and a transfer upon it reports kal_err_invalid (the report's third point; clause 6.7: a released handle is not treated as valid).
• tests/a_released_handle_is_stale_before_its_number_is_free.cpp: one context accepts and closes connections, one connects and closes, one opens, reads and closes a file for three seconds. Without the change: 94 files of 3.4 million read nothing of the file, and a released file's stream read standard input. With it: none.

Not changed: open failing with kal_err_io when the process has no descriptor left. openkal's conditions name no exhaustion of handles, and the leak that reached it in the report is the stale handle above.

The same construction is in openkal-macos (mcpplibs/openkal-macos#47) and openkal-windows.