docs: post-1.8.9 verification — pipeline confirmed, routing failure root-caused to framework-pt's disabled channel

docs/incident-2026-09-01.md

@@ -67,13 +67,34 @@ built and verified to embed the alias fix. `cargo fmt` applied.
   channel confirming / balance on the far side / payment couldn't route /
   genuinely no channels. Ships in the next release; needs its own
   create-release run (one more mnemonic paste). The CHANGELOG entry for
-  v1.8.10 should carry it.
+  v1.8.10 should carry it. Note the stale-direction defect it fixes: the
+  payment-failure mapper never set the direction, so a SEND failure showed
+  the RECEIVE-branch copy ("Receiving needs inbound liquidity…") — the exact
+  modal users saw while their node had a healthy 583k-outbound channel.
 - Nodes poll for OTA updates on `daily_check` — after publishing, tell the
   user to hit Update rather than wait for the next check.
 - `origin` remote had a stale pushurl with a dead token (pushes failed);
   fixed to the canonical repo URL, stale `~/.git-credentials` entry with an
   encoded port removed.
 
+## F. Post-v1.8.9 verification on shorty-s (2026-09-01 evening)
+
+- v1.8.9 applied; payment pipeline confirmed live: a 400,000 sat payment
+  SUCCEEDED through the v2 router route; the 404s are gone.
+- App gate serves TLS on 4080/8334/18083/50002 (401 gate pages over https) —
+  https app frames now answer. Mempool over https requires a hard refresh
+  (PWA precaches the old bundle).
+- **"No route to the recipient" on sends is real**: the invoices being tested
+  are from framework-pt, whose only channel (peer "Sandwich Farm",
+  0224c955…) is flagged `disabled` on BOTH policy sides in the routing graph
+  after today's node churn — the peer connection never re-established
+  (LND's reconnect backoff can stretch to hours). A disabled edge is
+  unroutable in both directions, so payments to/from framework-pt fail
+  regardless of shorty's 583k outbound. Fix: `lncli connect` the peer, wait
+  for the channel_update to re-enable the edge (~minutes), then re-test.
+- The 577k attempt earlier failed for a different, correct reason: it exceeded
+  the channel's spendable balance (583,542 − 9,850 reserve ≈ 573k max).
+
 framework-pt immediate workaround until its OTA lands: open the dashboard by
 IP (`http://192.168.x.x`) instead of `framework-pt.local`, and/or clear the
 cached policy once via `chrome://net-internals/#hsts` → Delete domain security