PPPOE-HA: record the two failure modes found by running the thing

Both were invisible to inspection and only appeared under the hard matrix:
the flap damper tearing down an established session via the lease it stopped
renewing, and a missing peers file being completely silent. The second has a
production edge worth spelling out -- an unsaved commit reverts on reboot and
takes pppoe0 with it, leaving a standby that can never take over while
looking perfectly healthy.

migration/PPPOE-HA.md

@@ -62,12 +62,45 @@ either "I do not hold the VIP" or "the lease is stale".
 
 | | |
 |---|---|
-| Clean failover (`force-fault`) | `pppoe0` moves in **26s**, reproducible |
+| Clean failover (`force-fault`) | `pppoe0` moves in **20-26s**, reproducible |
 | 10 gig down → PPPoE | route falls to `pppoe0`; LAN back online in **5s** |
 | Stale lease | guard hangs up within ~5s |
 | Missing peers file | `NRestarts=0` — no loop |
+| Flap holdoff vs live session | session survives a forged 900s holdoff |
 | Invariant | AC never showed two `simdsl` sessions |
 
+## Two failure modes found by running it, not by reading it
+
+**The flap damper tore down a healthy WAN.** `ppp_dial()` checked the hold-off
+and returned *before* renewing `may-dial`. That file is a lease the guard
+expires after `LEASE_TTL`, so tripping the damper stopped the renewal and the
+guard hung up `pppoe0` **on the master** ~80s later:
+
+```
+DIAL FLAP: >=6 attempts in 600s -- holding off 900s
+GUARD: lease stale (81s > 75s) -- hanging up pppoe0
+```
+
+A damper meant to suppress repeated *dials* was destroying an established
+session instead. An active session now renews the lease and returns before
+every other check; everything below only decides whether to start a **new**
+session. T12 is the regression test.
+
+**A missing peers file is silent.** `/etc/ppp/peers/pppoe0` is both pppd's
+options file and the gate's second condition, and it is only written by a commit
+that touches the pppoe subtree. Without it systemd logs
+`skipped because of an unmet condition check` exactly once and then nothing —
+a router that cannot dial at all looks identical to a healthy backup.
+`ppp_dial()` now says so on every tick, and distinguishes the two causes:
+configured-but-not-rendered (re-commit the subtree) versus no `pppoe0` in the
+config at all.
+
+The second cause is the one to watch in production: **a commit that was never
+`save`d reverts on reboot and takes `pppoe0` with it.** That is exactly how the
+sim secondary lost its WAN and spent hours looking like an ISP problem. After
+any hand commit to the pppoe subtree, `save` — or the next reboot produces a
+standby that can never take over.
+
 ## Deploying (not yet done)
 
 1. `sudo /config/vyos-known-good save` on both.