The suite can be given flags of its own, and the portable example builds again

[Sunrisepeak]

The suite can be given flags of its own, and the portable example builds again

THE PORTABLE EXAMPLE BUILT NOWHERE, AND THE PINS ARE WHY. src/main.cpp was
updated for 0.11's kal_spawn -- one struct where there had been three
declarations -- and examples/portable/mcpp.toml still pinned openkal 0.10.0:

src/main.cpp:256:19: error: 'kal_spawn' does not name a type

identically for the host and for every cross target. A version pin in an
example is a claim about what that example builds against, and nothing was
checking it: the program is not in any package's build, so no repository's
continuous integration compiled it. The four pins now name the published
versions, and the example runs -- 0 observations that did not hold on the host.

AND IT GAINS THE THREE PLATFORMS, WHICH IS TWO LINES AND NOT THREE.

Android NO LINE. aarch64-linux-android has os = "linux" because the
kernel IS Linux; bionic is a C library above it, and an
implementation written on the kernel's own interface does not know
which C library sits above it. cfg(os = "linux") already selects
openkal-linux for both ABIs, and an Android line would be a
second name for one answer.
iOS ONE LINE, no package. Darwin is Darwin -- the same traps, the same
call numbers, the same calling convention -- and what differs
between macOS and iOS is the SDK and the deployment-target flag,
which belong to the build tool. cfg(os = "ios") matches all
three iOS rows.
Web ONE LINE and new software. openkal-emscripten is the first
implementation in this ecosystem written ABOVE a C library, which
clause 2 permits in as many words.

FLAGS THE SUITE ITSELF HAS TO CARRY (OPENKAL_CONFORMANCE_SUITE_FLAGS).
OPENKAL_CONFORMANCE_IMPL_FEATURES names features of the IMPLEMENTATION, and
for every platform so far that was the whole of what an unusual arrangement
needed. Emscripten is the first where it is not: its thread support is selected
by -pthread, which chooses a different C library build, a different memory
model and a different loader contract, so it is a property of the WHOLE LINK.
Measured with the implementation's feature active and the suite built without
the flag:

DID NOT HOLD an execution context starts
DID NOT HOLD four execution contexts start
DID NOT HOLD contexts that ran at the same time have identities distinct

which is the suite being right: if openkal.task is provided, a context
starts. The variable adds the flags to the suite's compile AND link, because a
flag that selects a memory model must reach every translation unit and the
link, and one that reached half would produce a suite whose halves disagree.

It does not yet reach far enough, and that is recorded rather than papered
over: the specification package's own modules are compiled without it, so a run
with the variable set now fails with

error: POSIX thread support was disabled in precompiled file
'.../pcm.cache/openkal.types.pcm' but is currently enabled

A whole-graph flag channel is an engine change; openkal-emscripten gates the
interface behind a feature so that the absence is a link error rather than a
present-and-failing operation, and its README carries the rest.

AND THE FEATURE STAMP HAS TWO AXES NOW. The paragraph in this script about a
feature-set change not invalidating the build applies to the new variable
identically, and the first run that used it reported the previous run's build:
a module cache compiled without the flag. The record is now features|flags.

check-surface.sh TAKES $NM. A wasm object is not an ELF, and the host's
binutils nm reports "file format not recognized" for one; the reader that
does read it ships with the toolchain that produced it. Named in the
environment like the runner and the features, with the default unchanged. Same
class of defect as the leading-underscore note beside it, and found the same
way: by writing another implementation.