Record and expose how every process ends (M17.2)

The kernel records an ExitReason at all three death sites — clean exit,
fault (classified by vector), and process_kill — into a bounded ring
before the exit notification posts, so a supervisor's query never races
the notice. process_exit_reason is gated by the same supervisor check as
kill; runtime.process.exitReason is the stable interface. This is the
input restart policy reads (docs/process-lifecycle.md iron rule 2).

docs/process-management.md

@@ -101,8 +101,12 @@ the architecture layer calls up into `tick`.
   again — the cleanup half of [process-lifecycle.md](process-lifecycle.md)'s iron
   rule 1. The `claim-release` test proves the kill → release → re-claim cycle.
 - Kernel stacks of dead tasks are leaked, as on every exit path (no reaper yet).
-- There is no exit *status* in the notification, only the id; a supervisor that
-  needs the code can grow a wait-style call later.
+- ~~There is no exit status in the notification~~ Closed (M17.2): the kernel
+  records how every process ends — exited, a fault class, or killed — before it
+  posts the exit notification, and the supervisor reads it with
+  `process_exit_reason` (`runtime.process.exitReason`). This is the input to
+  restart policy ([process-lifecycle.md](process-lifecycle.md)); an exit *code*
+  for the clean case can still ride alongside later.
 - Enumerate writes through the caller's raw pointer under the bring-up trust
   model, like `device_enumerate` (an unmapped page is a self-DoS, not an
   isolation break).