Compose sockets, datagrams, readiness and fork above openkal 0.8

[Sunrisepeak]

Reported as mcpplibs/openkal-linux#13 and mcpplibs/openkal-musl#13: a
program above this library was told ENOSYS for socket, bind, listen,
accept, connect, poll, select and fork, and could not declare hidden
as an ordinary identifier.

openkal 0.8 added the atoms for all of the first group. Nothing above them used
any of them: musl's network sources compile and issue system calls the
dispatcher had no case for. The gap was here, not in musl's sources and not in
the specification.

What is added

port/src/okm_net.c	the socket family upon openkal.net, the datagram family upon openkal.datagram
port/src/okm_poll.c	readiness upon openkal.timeout
port/src/okm_fork.c	duplicating the calling image upon openkal.space

⚠️ BSD makes a socket first and decides what it is afterwards; openkal has no
object between "nothing" and "a connection". So a descriptor made by socket
holds the three numbers it was given, and the openkal operation happens at the
call that says what the socket is for — bind records an endpoint, listen
spends it, connect spends its own. A caller cannot observe the deferral: every
error a kernel reports at bind this port reports at listen, one call later
and with the same value.

⚠️ openkal has no operation reporting whether a transfer would proceed, and
clause 6.3 records why. poll therefore attempts the transfer under a bound and
keeps what it produced — one byte, one connection, one message — for the
operation that follows. POLLIN asserts that a read will not block, and a byte
already in hand is the strongest form that assertion can take.

Two corrections to the plan this implements

⚠️ posix_spawn was never missing. The plan said the exclusion of
musl/src/process/posix_spawn.c had to be answered by a port implementation.
port/src/okm_spawn.c has replaced that source since the port was written,
and system and popen work through it. Measured: system("exit 5") returns
an exit status of 5, popen carries a line back. What was missing was a
criterion — examples/subprocess is it.

⚠️⚠️ timeout_ns = 0 does not mean "do not wait". It means no bound;
timeout.h says so and kal_task_wait established it. Passing a caller's zero
straight through turns the one call that must not wait into the one that never
returns — measured, as a hang, four lines into the network probe.

⚠️ And SYS_clone is not the only number fork arrives through. musl's
_Fork issues SYS_fork where the architecture has it, so a dispatcher
implementing only SYS_clone is reached on aarch64 and riscv64 and never on
x86_64.

fork is composed here, and the specification asked for it

space.h states in terms that a library above reaches fork by saving its own
execution state before the call and restoring it in the started context, and
that this belongs above the line. okm_setjmp.S already carried the
per-architecture half.

An earlier reading of the report concluded that fork had been declined
deliberately. Half of that is right: clause 7.1 declines to duplicate an address
space and its execution state. openkal.space supplies the first half by
itself, and what was missing was never an atom.

What is refused, and why each refusal is stated rather than approximated

• permission bits — kal_node_info carries a boolean writable, not a mode
  word. Mapping the owner-write bit onto it would make chmod(0600) succeed and
  stat report something else.
• symbolic links — SURFACE.txt has no operation that creates one. It does
  have kal_node_link and KAL_FS_PROP_LINKS, so an implementation can report a
  link and cannot make one; the asymmetry is the specification's and is recorded.
• out-of-band data, readiness sets (epoll stays withheld).
• O_NONBLOCK where openkal.timeout is absent — it used to be accepted and
  carried no further, which is the one shape this port exists to avoid.

Criteria

Four probes, each written against POSIX, naming no openkal symbol, and each
stating on its command line what it expects the backend beneath to provide — so
a refusal is asserted as a refusal rather than merely not asked about.

examples/net	35 observations over a listener, a connection and two datagram endpoints
examples/subprocess	another program started three ways; --no-fork requires the refusal
examples/identifiers	hidden, weak, weak_alias as the program's own names — a compile-time criterion
examples/posix	unchanged, 32 observations

And in continuous integration: eleven names asserted weak, with
kal_time_sleep as the strong control. A strong reference to any optional
interface would make a bare-metal program that never opens a socket fail to
link — the defect that step already exists because of, arriving through a new
name.

⚠️ The first form of that check reported two failures, and both were the
check's fault: a search under target/ reaches the dependency's objects,
where openkal-linux's kal_timeout_accept refers to its own kal_net_accept
strongly. That is correct for an implementation and says nothing about this
port.

---

This is one change across seven repositories, and every branch carries the
same name. Each repository's continuous integration substitutes its siblings'
working trees taken from the branch of the name under test, so the graph only
holds together when they agree.

repository	what it carries
openkal-musl	the socket, datagram, readiness and image-copying routes, and four probes
openkal-macos	the five interfaces 0.8 added
openkal-windows	four of the five; openkal.space declined in terms
openkal-linux	the conformance run selects the optional interfaces, which nothing did
openkal-llvm-runtime	__config_site's claims asserted by a program, and the C library repinned
openkal	the portable example's pins, and §9 of the plan
sbase	ninety-seven utilities above the new C library

The specification does not change. No interface was added, none was altered,
and SURFACE.txt is untouched — every capability below is composed from atoms
openkal 0.8 already had.