stp: warn when an enabled port cannot receive BPDUs

A port set to admit tagged frames only will never see a BPDU, because
delivery rides the forward action and the ingress pipeline drops untagged
frames before the L2 lookup. The failure is silent and looks like a dead
receive path: the port turns edge after three seconds, the bridge elects
itself root, and nothing hints at the ingress setting. Diagnosing exactly
that cost most of a day on a live switch, with the neighbour provably
transmitting the whole time.

stp_setup() now prints one line per affected port, so the hint lands at
"stp on" and at every config replay on boot. The check runs in its own
loop after the MSTP write: port_ingress_filter_get() reads a register
into sfr_data, which the state-building loop above is still using. The
port number in the message is physical, matching what the ingress
command takes.

doc/stp.md explains why this can happen here and not on a normal bridge,
where BPDUs are consumed before any VLAN classification.

stp.rel stays at DSEG 5 with no OSEG and the image at 10498 bytes of
XDATA.

doc/stp.md

@@ -64,6 +64,17 @@ by a static L2 multicast entry (`port_l2mc_set()`), one per VLAN in use:
   transparency an unmanaged switch is expected to have, so a surrounding
   spanning tree can span *through* this device.
 
+Because delivery rides the forward action, a BPDU is an ordinary frame to the
+ingress pipeline and is subject to the port's acceptable-frame-type setting.
+BPDUs are untagged by definition, so a port configured to admit tagged frames
+only (`ingress <port>t`) will never deliver one: a port left on the default
+auto edge turns edge after three seconds of silence, one with edge switched off
+sits out the full forward delay instead, and either way the bridge elects
+itself root no matter what the neighbour sends. `stp_setup()` prints a warning for every
+STP-enabled port in that state. On a normal bridge this cannot happen, since
+BPDUs are consumed before any VLAN classification; here it is a direct
+consequence of the delivery path above.
+
 Port states live in `RTL837X_MSTP_STATES (0x5310)`, two bits per port:
 `00` disabled, `01` blocking, `10` learning, `11` forwarding. Note that a port
 held in blocking also drops frames the CPU injects into it, so a blocked port