nx_cap.nx

cap.nx -- capability-based security primitives. EFFICIENCY_ROADMAP §5.4. Today every .nx file can call any syscall (sys_execve, sys_openat, etc.) because the function symbols are linker-resolved with no access control. That's fine for a single-author project; it's a disaster once we import third-party code. This module ships capability tokens that can be REQUIRED at function-signature level. A function that wants to open a file takes a `*CapFS` argument; if the caller didn't get that capability from the root process, they can't forge one (we don't expose a fake constructor). Three delivery phases: A (this file): capability types + a root-only constructor. Library code adopting `fs_open(cap: *CapFS, path: *u8)` becomes sandbox-aware immediately; old `fs_open(path)` callers keep working until migration is complete. B (parse.nx change, pending): `@requires(CapFS)` function attribute lifts this into the type system. Compiler refuses to compile a function that calls fs_open without a CapFS in scope. C (import.nx change, pending): every import statement declares what caps it needs. main.c picks them up + ensures the top-level main has the superset granted. Invariants: CAP1 Capabilities can NOT be forged -- only created through cap_root_grant which the root/init code holds. CAP2 A capability can be narrowed (cap_narrow returns a strictly weaker capability). CAP3 Capabilities can be revoked; revoked caps reject all operations + can't be re-enabled.