stp: correct what the blocking state does

A blocked port does pass a received BPDU up to the CPU. The evidence is in
logicog's capture of a looped pair: the port the loop check had already
blocked kept reporting a BPDU age of zero seconds across dumps taken more
than a forward delay apart, and that counter is only cleared in stp_in().
That is also what makes the loop latch work, since the port that stays
forwarding has to go on hearing the blocked one.

The tag flag comment said the source address is not learned on the egress
port. doc/CpuPort.md defines it as not learning the source address from the
frame at all, which is the narrower claim to make. The dangling heading
above it described a field that is documented there too.

doc/stp.md

@@ -59,9 +59,10 @@ to the CPU. `stp_setup()` prints a warning for every STP-enabled port in that
 state.
 
 Port states live in `RTL837X_MSTP_STATES (0x5310)`, two bits per port:
-`00` disabled, `01` blocking, `10` learning, `11` forwarding. In the blocking
-state a port forwards nothing except frames sent by the CPU, and nothing it
-receives reaches the CPU.
+`00` disabled, `01` blocking, `10` learning, `11` forwarding. A port in
+blocking forwards nothing between ports, but it still sends what the CPU
+hands it and still passes a received BPDU up to the CPU, which is what lets
+loop detection go on working on a port it has already blocked.
 
 ## Timers