0.9.0 — the word this kernel could not set without a trampoline of its own

[Sunrisepeak]

kal_process_stop_requested answered null here while two other implementations
answered a word. The reason was never the specification: the raw sigaction of
this kernel takes a structure whose SECOND field is sa_tramp, the kernel
enters THAT address rather than the handler, and the C library that ordinarily
supplies it (_sigtramp) is not beneath this implementation.

⚠️ A wrong trampoline is not a wrong answer — it is a program that dies inside
the handler at an address belonging to nobody. So the order was: the check
that raises the signal first, the trampoline second. The check installs the
disposition, has a shell raise SIGTERM at this program, waits on the word
through kal_task_wait, and then asserts the program is STILL RUNNING — which
reaching the line proves and a compiled disposition cannot show.

⭐ arm64 only, and that is the whole of it rather than half: the CI matrix is
macos-14 alone because the build tool has no x86_64 release for this system,
so a trampoline there could be compiled and never entered. Clause 6.2 makes the
absence a fact a caller reads, and kal_process_props claims the position only
where it has been run.

⚠️ The test is this ecosystem's first consumer of openkal.macros, and writing
it is how the module's own gap was found — see openkal.