stp: turn the management failsafe into a one-shot window

The failsafe used to watch management traffic for as long as STP ran, so
three minutes of nobody looking at the web UI took the tree down on any
quiet network. That made a standing STP config impractical, which is the
problem raised in the review of the original PR.

Enabling STP arms a window of stp_failsafe_s seconds. One HTTP request
inside it confirms that management survived the new tree and disarms the
watchdog; a silent window disables STP and restores forwarding. Both
outcomes print to the console and the syslog.

The window re-arms on any later event that newly takes a port out of
forwarding: a port rejoining via "stp port N on", root guard firing, the
loop latch. Those were covered by the old always-on surveillance and a
disarmed window would have left them able to cut management off for good.
If management traffic keeps flowing past the new block, the next request
confirms straight away, which is the correct verdict, the block did not
cut it. The arming deliberately does not refresh an already armed window:
root guard can re-fire on every hello, and refreshing the countdown on
each one would keep a cut-off window from ever expiring. A stable network
with nothing newly blocked never re-arms, which is the reviewed-for
behaviour.

The request or console command that causes the arming never counts as its
own confirmation: mgmt_alive is cleared when a command arms, and the
console hook only disarms when the window predates the command. Without
that, enabling from the web UI or the console would confirm the window
before the new tree had any chance to cut management off.

A command on the serial console confirms like HTTP does. An operator at
the console has out-of-band access that no tree can cut, so the automatic
restore only takes STP away from someone equipped to deal with the
situation. The hook sits on the interactive console path only, identified
by cmd_available, so neither the config replay at boot nor HTTP commands
pass through it.

After a confirmation STP runs unsupervised until something new blocks.
Headless installs where nobody will confirm should set stp failsafe 0;
doc/stp.md says so.

Costs two bytes of XDATA, the armed flag and the console-path snapshot;
stp.rel and rtlplayground.rel keep their segment sizes.

doc/stp.md

@@ -142,16 +142,32 @@ Enabling STP on a switch you administer over the network is a genuine risk: the
 management VLAN rides a port that STP may put into blocking, and once that
 happens the way back is a power cycle.
 
-The firmware therefore runs a commit-confirm watchdog. While STP is enabled,
-any HTTP request re-arms a countdown; if management stays silent for
-`stp failsafe <seconds>` (default 180, 0 disables it), STP disables itself and
-restores forwarding. Keeping the web UI open on the Spanning Tree page is
-enough to hold it off, since the page polls for status.
+The firmware therefore runs a commit-confirm watchdog. Enabling STP, by hand or
+from the startup config, arms a one-shot window of `stp failsafe <seconds>`
+(default 180). One HTTP request inside the window confirms that management
+survived the new tree and disarms the watchdog until the next enable; a window
+with no management activity disables STP and restores forwarding. After the
+confirmation STP runs unsupervised, so a quiet network no longer loses its
+tree to three minutes of nobody looking at the web UI.
 
 ```
-stp failsafe 180        # seconds of silence before STP gives up (0 = never)
+stp failsafe 180        # length of the armed window after enabling (0 = never armed)
 ```
 
+Any later event that newly takes a port out of forwarding arms the window
+again: a port rejoining via `stp port <n> on`, root guard firing, the loop
+latch. If management traffic keeps flowing past the new block, the very next
+request confirms and disarms; if the block cut it, the silent window restores
+forwarding as above. A stable network with nothing newly blocked never re-arms.
+
+A command executed on the serial console also confirms, on the grounds that an
+operator with out-of-band access does not need the automatic restore; the
+command that enabled STP does not count, only activity after it.
+
+A headless switch that nobody confirms over HTTP should set `stp failsafe 0`,
+otherwise a reboot with STP in the startup config disables it again three
+minutes later. Setting a new value while STP runs arms a fresh window.
+
 The status page shows whether the failsafe has tripped since STP was last
 enabled.