net: a frame wakes the stack, instead of waiting for the clock

The network thread waited on the timer and nothing else, so a frame that landed
just after a poll sat in the ring for up to 10 ms -- the largest fixed latency in
the system. That was deliberate when the stack was new (a receive path woken by
an interrupt is much harder to debug than one that is asked) and there is now a
working stack to compare against, which is exactly when it becomes safe to do.

The frame is still *pulled* by the thread through .receive. It has to be: a call
into lwIP can reach the driver, the driver can sleep on the buffer cache, and an
interrupt handler may do neither. netdev_rx_signal() delivers nothing and reads
no ring -- it only ends the wait early.

The wait stays on the timer tick rather than moving to a channel of its own, and
that is the design. lwIP's timers must still run when the link is silent, so the
clock has to remain a floor under the wait, and sleep() cannot wait on two things
at once. Joining the tick's existing wakeup costs nothing and leaves one wait
with one predicate.

rx_signal lives under tickslock for the same reason it gets no lock of its own:
sleep() releases tickslock atomically, so a driver setting the flag and waking
under that lock cannot lose the wakeup by arriving between the predicate test and
the sleep. A private lock would not be held across the sleep, and that window
would be back. Calling it from interrupt context is safe on the same terms the
timer handler already relies on -- acquire() disables interrupts, so a CPU
holding tickslock cannot be interrupted into it.

The e1000 signals on RXT0 (a frame or burst has landed) and RXDMT0 (the ring has
fallen below its threshold, which is when waiting for the clock hurts most).

Measured rather than asserted: /proc/netif reports wake_rx and wake_tick, and
across three pings rx_frames and wake_rx both went 2 -> 6 -- every received frame
woke the thread through the interrupt. wake_tick keeps advancing as the idle
floor, which is what lwIP's timers need. socktest still passes and ping is still
0% loss.

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

docs/plan/1.0.md

@@ -101,9 +101,13 @@ These are the galling ones — the replacement exists, is tested, and is unused.
       `text.c` and `ttf.c` both exist and work. The console still indexes
       `font_data[256][16]`.
 - [ ] **Load a font from disk** and point the console at it.
-- [ ] **Interrupt-driven receive.** The network thread polls the NIC every timer
-      tick, so a frame waits up to 10 ms. Waking it from the e1000 interrupt was
-      deliberately not the first version; it is time.
+- [x] ~~**Interrupt-driven receive.**~~ The e1000's handler calls
+      `netdev_rx_signal()`, which ends the network thread's wait early; the frame
+      is still *pulled* by the thread, because an interrupt handler can neither
+      sleep on the buffer cache nor take the lwIP lock. The wait stays on the
+      tick so lwIP's timers keep their floor. Proven rather than assumed:
+      `/proc/netif` gained `wake_rx`/`wake_tick`, and across three pings
+      `rx_frames` and `wake_rx` both went 2 -> 6.
 
 **Structural, because everything after this compounds on it:**