library: the harness keeps the subscribers, and an id belongs to whoever opened it

Three services had each written the same thing and got it three different
ways: input polled the process list to notice a dead subscriber, and only
when someone else subscribed; the power service never noticed at all; the
device manager noticed drivers but not subscribers. The harness owns the
table now, driven by the events a protocol declares — it registers on the
reserved verb, frames each event once, posts to everyone interested without
waiting on any of them, and reclaims a slot when the kernel says its owner
died. Interest masks moved to the envelope, so a subscriber that wants only
mice asks the same way everywhere.

Two consequences the plan had not foreseen. The device manager now hears a
supervised child's death twice, once as its supervisor and once as a
subscriber, so restart backoff counted every crash twice and gave up after
half as many; it retires the id before counting. And the kernel's published
exit table had eight slots for what is now six subscriptions in a plain
boot, so it holds sixteen.

The other half is a hole the design named early and left standing: a
backend handed out a small integer and then honoured it from anyone. A
process that guessed a file's node id read another client's file; a display
layer had no owner at all, so any client could reconfigure or destroy any
layer; a USB device token was never checked against the client that opened
it. Each is now bound to the task that opened it, and a wrong owner gets
exactly what an unknown id gets — the refusal must not become the oracle
the identical answers elsewhere were designed to remove. Closing a file
changed with it: it used to succeed unconditionally, which would have told
a caller which ids existed.

Suite 111/111, with a new case in which one process holds a file and a
layer, hands both ids to a second process, and finds them untouched after
that process has tried everything with them.

docs/file-system-development/vfs-protocol.md

@@ -212,10 +212,24 @@ Open-node ids live in the backend. A client that dies without closing leaks
 nothing permanently: the backend (the FAT server) subscribes to the kernel's
 published process-exit events (docs/process-lifecycle.md) and releases a dead
 client's handles. The kernel VFS root needs no sweep at all — its node tokens
-are permanent for a boot and carry no open state. Ids are plain integers, not
-capabilities — a backend trusts its callers with each other's ids today, which
-is acceptable while every client is part of the system image and worth
-revisiting (per-client id namespaces) before third-party binaries arrive.
+are permanent for a boot and carry no open state.
+
+Ids are plain integers rather than capabilities, so the backend **scopes them
+to the caller's badge**: an open node belongs to the task that opened it, and
+every verb that names one — read, write, status, readdir, close — is answered
+only for that task. A node id is a small number drawn from a table of
+thirty-two, trivially guessable, and until this rule a backend honoured every
+client's ids from every other client
+(docs/os-development/protocol-namespace.md: *handles must be scoped per
+client — validated against the badge, or drawn from a per-client id
+namespace*).
+
+The refusal is deliberately **identical to absence**: a node that is somebody
+else's answers `-ENOENT`, exactly as one that was never opened, so a prober
+learns nothing about which ids are live — the same discipline the protocol
+namespace applies to a refused open. The owner is a *task*, because the badge
+is: a threaded client uses a node from the thread that opened it, which is
+already the granularity of the exit sweep that releases it.
 
 ## Evolution rules