feat(kernel): derivation-tree revocation, region caps

- caps record parent (mint/delegate/ipc), CapRef w/ pid+slot gens
- Revoke = delete subtree, keep self; drop/death re-parents children
- CreateRegion/MapRegion; mapping lives only as long as its cap
- drop Permission::Revoke + object-wide revoke
- mint any cap (badge only ep/ntfn), process caps delegable
- kani: descendants == subtree; model-based fuzz vs spec

docs/ipc.md

@@ -19,8 +19,25 @@ Both are named by capabilities whose generation must match (see P2).
 ## Capabilities
 
 A capability to an endpoint or notification carries a **badge** (a word;
-`0` means unbadged). `Mint` copies an unbadged capability with a badge and
-narrower permissions. A badge cannot be changed once set.
+`0` means unbadged). `Mint` copies a capability with narrower permissions
+and, for endpoints and notifications, a badge. A badge cannot be changed
+once set: a badged capability cannot be minted again.
+
+## Derivation and revocation
+
+Every capability made from another (by `Mint`, `Delegate` or an IPC
+transfer) records it as its **parent**; capabilities the kernel creates
+directly have none. `Revoke(cap)` deletes every capability derived from
+`cap`, transitively and across processes, and keeps `cap` itself. Any
+holder may revoke, but only its own subtree.
+
+Deleting a capability (`DropCap`, or its process dying) makes its parent
+adopt its children, so stepping out of the chain never shields anyone
+from a revocation further up.
+
+A region mapping made with `MapRegion(cap, va, perms)` lasts only as long
+as `cap`: deleting or revoking `cap` unmaps it. `perms` needs `Read`, plus
+`Write` for read-write or `Execute` for read-execute.
 
 | Object       | Permission | Allows                                     |
 |--------------|------------|--------------------------------------------|