proc: real CPU time, a tty number, and an exe that is a symlink

Four Gate 0 rows, and a fifth found while checking one of them.

**getrusage() did not distinguish RUSAGE_CHILDREN from RUSAGE_SELF**, which
undersells it: it ignored `who` entirely and reported the machine's *uptime*
as the caller's user time. Every process of every age answered with the same
number. Per-process CPU time is sampled at the timer tick now and split on the
interrupted privilege level; children's time is rolled up in wait() rather than
exit(), because RUSAGE_CHILDREN means *reaped* children and a running one has
not contributed yet.

**And wait4()'s fourth argument is a `struct rusage *` that was read off the
stack and thrown away.** That is the one shells actually use -- wait3() is the
same syscall with pid -1 -- so zsh's `time` reported

    16777216.01s user 1073.78s system 927983249% cpu

for every command. 2^24 seconds is uninitialised memory, and it did not vary
with the workload because it was never written. Now:

    busy loop   2.66s user  97% cpu   2.720 total
    sleep 2     0.02s user   0% cpu   2.248 total
    ls -lR /    0.70s user  65% cpu   1.070 total

**ru_stime is a structural zero and says so.** MSR_SFMASK includes FL_IF, so
SYSCALL clears interrupts and no tick can land while a process is inside a
syscall. Tick sampling cannot see kernel time at all here. Charging it needs
TSC deltas closed and reopened around every sched(), which is scheduler
accounting rather than sampling; the limitation is written down in
docs/architecture/kernel.md rather than papered over.

**/proc/<pid>/exe is a symlink.** It also needed a real st_size, and every
other procfs file deliberately reports zero -- readlink(2) bounds its copy by
it, so a symlink of size 0 resolves to the empty string, which looks like it
worked and is worse than the regular file was. Generating that one path in
ilock() costs one small render per stat() of one file.

**OVMF memory reporting is closed**: 1 GB reports 1017 MB usable, 2 GB reports
2041 MB. The firmware keeps about 7 MB either way, which is the right shape.

**And `ps` printed a header and nothing else**, which is not in any list
because nobody had run it. `ps` with no arguments shows only processes on
*this* terminal; /proc/<pid>/stat hardcoded tty_nr to 0, so nothing could ever
match. `ps -e` always worked, which is exactly what hid it. p->ctty was already
tracked -- procfs simply was not asked. Fields 14..17 were hardcoded zero too,
so TIME read 00:00:00 however long a process had run; they carry the new
counters now, and a shell that has burned 653 ticks reports 00:00:06.

Verified: utime climbs 18 -> 653 across a loop in the shell itself, `ps` lists
its own terminal, `ps -e` still lists everything, `readlink /proc/1/exe` gives
/bin/schinit, and sigtest/$()/rename/dmesg are all still green.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

include/proc.h

@@ -166,6 +166,9 @@ struct procinfo {
   int    state;             // enum procstate
   uint64 sz;
   int    killed;
+  int    ctty;              // controlling terminal, 1-based; 0 = none
+  uint64 utime, stime;      // CPU time in ticks, this process
+  uint64 cutime, cstime;    // and its reaped children
   char   name[16];
   char   exe[64];           // full path, for /proc/<pid>/exe
 };
@@ -213,6 +216,16 @@ struct proc {
   struct ioport_range ioport[NIOPORT];
   int nioport;
 
+  // CPU time, in timer ticks, charged by trap() at each tick to whoever was
+  // running. utime/stime split on the interrupted privilege level -- cs & 3 --
+  // which is the only information the tick carries about what it interrupted.
+  //
+  // cutime/cstime accumulate *reaped* children, and only reaped ones: that is
+  // what RUSAGE_CHILDREN means, and it is why they are rolled up in wait()
+  // rather than in exit(). A child still running has not contributed yet.
+  uint64 utime, stime;
+  uint64 cutime, cstime;
+
   uint64 signal_mask;
   uint64 pending_signals;
   int alarm_ticks;