0.10.0 — the exec search, and the family of answers that were not true

[Sunrisepeak]

openkal-linux#13, fifth round.

A consumer measured that execvp could not get past the first PATH entry that
missed, and that one libc path accounted for nine of their nineteen failures
plus four sections silently skipped (bwrap, installed at /usr/bin/bwrap,
reported as not installed). That is fixed — and reading it out found six more
of the same family, one of which is worse than the one reported.

⭐⭐ What they have in common, and why no diagnostic here could see them

Every probe in this repository asked whether an operation worked. None asked
whether an answer was true. OPENKAL_MUSL_TRACE=enosys reports what reaches
the default arm, and not one of these reaches it — they are operations that are
present and answer wrongly.

examples/surface is the probe that asks the other question, by comparing every
answer against the host's. It is how the six were found.

Reported by the consumer

execve did not return when the program could not be started	the replacement happens inside a duplicate, whose failure openkal-linux reports to nobody; the duplicate ended with 127 and execve ended the caller with it. __posix_spawn now asks whether the name can be started first
posix_spawnp never searched a PATH at all	musl hands __execvpe to posix_spawn to run in the duplicate; this port has no duplicate, so the field was read by nobody and posix_spawnp("sh", …) started ./sh and reported success. musl's source is now replaced — the tenth

⚠️⚠️ Found by reading it out — a lock was granted and never taken

fcntl(F_SETLK), F_SETLKW and F_GETLK answered 0 and did nothing. Measured
against the host: two programs took one exclusive lock and both were told they
had it. F_GETLK pointed the other way — it left the caller's word untouched,
which reads as "somebody holds this", for ever, so a loop waiting for a lock
never left it. All three report ENOSYS.

⭐ The refusal is temporary in a way the permission one is not: every
environment beneath openkal can lock a byte range (fcntl, LockFileEx), and
what is missing is a word in the specification. Composing one here from
KAL_OPEN_EXCLUSIVE is not an option — nothing would release it when its holder
died.

The rest

• ⚠️ getppid returned -38 as an identifier — the defect getpgrp had one
  release earlier, three lines away in the same dispatch, not looked for. The
  criterion added here asks the whole family.
• A copy made by fork reported its parent's identifier. Settled before the
  copy is taken and carried into it — and the comparison kill makes moved with
  it, or abort in a copy would have reported ESRCH.
• setpgid(0,0) and setsid refused a question neither asks → 0 and EPERM.
  Every daemonising library handles EPERM; none handles ENOSYS.
• sigaltstack reported an installation it had not performed → ENOSYS.
• sysconf(_SC_OPEN_MAX) answered 0 for a bound this library sets itself.
• utimensat could not set a directory's time — reported as a failure to
  read one, because libc++ gives both overloads of last_write_time one name.
  Reading was never broken.

What is NOT fixed, and is now recorded

kill does not reach a program started by fork + execve — it reaches the
copy that is waiting for it. Measured with the host as control: identical status
words, opposite outcomes. openkal has no way to say "this program's lifetime is
bound to mine", and kal_process_terminate is right to terminate only what it
was given. Asked of the specification; README says to use posix_spawn,
system or popen where a caller needs to stop what it started.

⚠️ README.md and musl/PATCHES.md claimed a caller cannot distinguish
execve-as-spawn+wait from a real replacement. That claim was false and is what
kept anyone from looking. Both now list the three known differences.

Criteria

• examples/surface is new: eleven of its observations fail on 0.9.0 and none
  does here.
• examples/subprocess gains the exec search and the identity. On 0.9.0 it does
  not merely fail — it stops, at the execve observation, which is the
  defect itself.
• ⭐ Two are guards rather than criteria (they hold before this change too):
  abort in a copy is still SIGABRT, and a failed fork gives its table entry
  back. Listing them beside the criteria would have made five of seven
  observations look like results.
• ⚠️ examples/posix asserted that setting a directory's time is refused, and
  its own comment said that observation would be the one to say the row was out
  of date. It was.