Move the portable example's pins, and record what the plan got wrong (#15)

* Move the portable example's pins, and record what the plan got wrong

The specification does not change. Two implementations do: openkal-macos
provides the five interfaces 0.8 added and openkal-windows provides four
of them, so the example that demonstrates one program above three
implementations names the versions that have them.

.agents/docs gains section 9 of the capability-completeness plan --- what
was implemented, the four decisions section 8 left open, and the five
things the plan itself got wrong. Two of the five are worth naming here:

  ⚠️ `posix_spawn' was never missing. openkal-musl replaced musl's source
  when the port was written, and `system' and `popen' have worked through
  it ever since. What was missing was a criterion.

  ⚠️⚠️ `timeout_ns = 0' does not mean "do not wait" --- it means NO BOUND,
  which timeout.h states and kal_task_wait established. The plan had it
  backwards, and passing a caller's zero straight through turns the one
  call that must not wait into the one that never returns.

And one thing nothing had noticed: no continuous integration anywhere
selected these interfaces. Every backend ran the conformance suite as
`full', which expands to the HOSTED set, so every section for net,
datagram, timeout, exec and space was compiled with its body removed and
reported as not examined --- in the same release that added them.

* Give the closure against published packages a place in the repository

Every workflow in this ecosystem substitutes its siblings' working trees
for the versions its manifests name. That is deliberate --- these
repositories change together --- and the consequence is that NO WORKFLOW
ANYWHERE RESOLVES A PUBLISHED PACKAGE. `openkal-kit' 0.1.0 shipped
naming the specification by a path, which is true inside its own tarball
and false for any consumer that also names an implementation; eight
packages published, nine workflows green and eight repositories green on
their own main, and the first resolution of the published set failed.

The script that asks that question existed only in a scratch directory.
It is here now, generalised over the versions and extended to exercise
the routes this release adds --- a listener, a connection, a transfer
and a duplicated image, written through POSIX and naming no openkal
symbol, so that a published C library whose sockets do not work cannot
satisfy it.

* The plan's status is its outcome, and the plan is left as written

* The exec section compiles under all three compilers, not two

⚠️ THE FIRST RUN IN WHICH THIS SECTION WAS SELECTED AT ALL is the run
that found it. openkal-windows now names `exec' in its feature set, and
the MSVC row stopped at

    exec.cpp(78): error C3861: '__builtin___clear_cache': identifier not
    found
    exec.cpp(82): error C3861: '__builtin_memcpy': identifier not found

The suite is built by three compilers and had been written against two.

The cache maintenance is guarded on the COMPILER rather than on the
architecture, because what varies is which compiler spells the operation
that way; where it is absent, the architectures that compiler targets
here keep the two paths coherent in hardware. The copy becomes a byte
loop: this suite reaches no C library --- it is written to run against an
implementation that may be the only supplier of one --- and a builtin is
not a C library, but it is not a language feature either.

* Record the five defects continuous integration found and reading did not

---------

Co-authored-by: speak-agent <x.d2learn.org@gmail.com>

Author: Sunrisepeak