kernel: chroot, #! scripts, rename and mmap as apk needs them

Found by running Alpine's apk on SchOS, one failure at a time:

- chroot(2) was a stub returning EPERM. Each process now has a root:
  where an absolute path starts and where .. stops. Mounts remember
  whose root they were made under, and a walk leaves a mount by the way
  it came in, so one filesystem can be mounted twice.
- devtmpfs and proc mounted only on /dev and /proc, whatever the target;
  a chroot got "already mounted".
- mmap never reused freed address space, so musl's malloc used up the
  256 mapping records while 780 MB were free. A mergeable mapping now
  goes straight after an anonymous one whose end has room.
- unlinkat returned -1 (EPERM) where apk expects ENOENT, and renameat
  was an old copy of rename: no replacing the target, and v1 dirents
  written into SchFS. Both now share rename's implementation.
- execve runs #! scripts, and says ENOEXEC for what it cannot run.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01S1giNvrHTrPMPw7V6x1kQ4

kernel/proc/proc.c

@@ -503,6 +503,7 @@ fork(void)
   np->gid  = myproc()->gid;  np->egid = myproc()->egid;  np->sgid = myproc()->sgid;
 
   np->cwd = idup(myproc()->cwd);
+  np->root = myproc()->root ? idup(myproc()->root) : 0;
   memmove(np->cwd_path, myproc()->cwd_path, sizeof(myproc()->cwd_path));
   np->fs_base = myproc()->fs_base;
 
@@ -662,8 +663,11 @@ exit(int status)
 
   begin_op();
   iput(myproc()->cwd);
+  if (myproc()->root)
+    iput(myproc()->root);
   end_op();
   myproc()->cwd = 0;
+  myproc()->root = 0;
 
   acquire(&ptable.lock);