0.12 — the unit a caller cannot name, and where a permission would have gone

[Sunrisepeak]

Two things a reader had to discover by writing code, and one module that was
generated for two versions without ever being imported.

Clause 11 entry 9 now names what it costs. It already said handles do not
cross an address space; it did not say what follows for units. A unit is
established by whoever starts a program, at the moment of starting it, so a
program cannot name a unit a COPY of itself went on to form — the copy's handle
is built from an index into the copy's own table (clause 6.7) and nothing
conveys it back. ⚠️ The failure this produces is not a refusal: an
implementation that meets the dead end is invited to reach for the nearest unit
it can name, which is its own. openkal-musl 0.12.0 did exactly that, and every
negative identifier that matched no child named the caller's own unit — an
enquiry about a unit that did not exist was answered yes, and a signal aimed at
one ended the caller together with everything it led. The entry records it so
the next implementation meets it here instead.

kal_fs_open and kal_fs_mkdir now point at entry 6. The cross-reference
existed at KAL_INFO_IDENTITY and kal_fs_lock — not at the two operations
that CREATE, which is where somebody wanting a private file looks. It is a
position and not a gap, and the position is WASI's: fs_rights_base attaches
to a handle and not to a file, and the analogue here is the flag word open
already takes.

⭐ openkal.macros had the defect it was added to prevent. It exists
because a macro does not cross a module boundary, and CI regenerates it and
diffs it — which asserts the file is up to date and never asserted that anybody
can use it. Nothing in this ecosystem had ever imported it. macros_reach.cpp
is the first consumer; it runs nothing and fails the build both when a name
does not resolve and when a value is wrong.