Drop swipe-to-next-article; bottom Previous/Next bar; smaller titles; bug report

- Dropped swipe-to-next-article entirely, per explicit instruction. Two
  different fixes for the gesture interfering with WebView scrolling had
  already been tried and didn't resolve the reported jerkiness (one even
  broke swipe outright and was reverted) -- rather than keep tuning gesture
  detection, removed the gesture altogether.
- ReaderScreen: new bottom bar with explicit Previous/Next buttons
  (disabled at the ends of the article queue), replacing swipe. This is
  the first slice of the "bottom action strip" backlog item. Verified
  live: Previous/Next correctly page through the article queue with the
  right enabled/disabled state at each end.
- Smaller title text: reader top bar title (titleMedium, was TopAppBar's
  default titleLarge) and article list row titles (bodyMedium, was
  ListItem's default bodyLarge).
- New "Report bug" action in the reader's overflow menu: a dialog for a
  short description, which gets bundled with the article's title/URL/id,
  feed id, reader-mode state, and save/Stash state into one text block
  copied to the clipboard on confirm (verified live, including the
  "Copied to clipboard" confirmation) -- enough to reproduce an issue in
  the tungsten emulator without needing live device access.
- BACKLOG.md: marked the done slice of the bottom-strip item, added a
  note on the scroll-jerkiness investigation so far (two ruled-out
  theories) since swipe removal may or may not affect it -- worth a fresh
  look now that nothing intercepts touches above the WebView at all.

1 files changed, 28 insertions, 28 deletions

diff --git a/BACKLOG.md b/BACKLOG.md
index b36d66c..6ed83cd 100644
--- a/BACKLOG.md
+++ b/BACKLOG.md
@@ -48,36 +48,36 @@ extracted or feed-provided HTML and swap it for a tap-to-play thumbnail
 tap, rather than trying to make the embed actually play inline (which would
 mean turning JS back on for untrusted third-party content).
 
-## Bug report button
+## Bottom action strip (partially done)
 
-**Motivation:** every crash/bug so far has been diagnosed by manually pulling
-logcat and querying the on-device DB over adb -- fine on tungsten's emulator,
-not available from the user's actual phone in the moment something breaks.
+**Done:** swipe-to-next-article dropped entirely (two different attempts at
+keeping it from interfering with WebView scrolling both failed to actually
+fix the reported jerkiness, and the second broke swipe outright). Replaced
+with explicit Previous/Next buttons in a new bottom bar -- no gesture to
+disambiguate with scrolling at all now.
 
-**Rough shape (not yet built):** a "Report bug" action (article overflow
-menu, or a dedicated crash-handler hook) that gathers what's needed to
-reproduce in the emulator -- the current article's URL/id, a short
-user-typed description, and whatever we've already instrumented internally
-(feed id, reader-mode state, isReaderMode/extraction state, recent logcat
-lines if reachable) -- and copies it to the clipboard as one block of text,
-ready to paste back into a message.
+**Still open:** the top bar is still crowded (reader-toggle, open-in-browser,
+bookmark, Stash, overflow) and top-heavy for one-handed use. Move those
+action icons + the overflow menu down into the bottom bar alongside
+Previous/Next, and auto-hide both the top and bottom bars together on
+scroll (hide on scroll-down, reveal on scroll-up or tap), matching the
+common "immersive reading" pattern other reader apps use.
 
-## Smaller title text
+## Scroll jerkiness (still open, root cause unknown)
 
-Article titles in the reader's top bar (and the list rows) read too large
-relative to everything else. Reduce the type scale -- exact size TBD by eye
-once tried.
+Reported as "jerky, loses track of my motion." Two theories tried and
+ruled out live, not just in code review:
+- An orientation-aware Compose gesture detector wrapping the WebView (for
+  swipe-to-next-article) -- kept working correctly for paging, but didn't
+  fix the reported jerkiness either, so it likely wasn't (only) about
+  gesture-arbitration overhead from that detector.
+- A passive native OnTouchListener replacing the above -- broke swipe
+  outright, reverted, and jerkiness was never re-tested in isolation since
+  swipe was still present in that build.
 
-## Bottom action strip
-
-**Motivation:** the reader's top bar is getting crowded (reader-toggle,
-open-in-browser, bookmark, Stash, overflow) and it's a top-heavy layout for
-a one-handed phone -- reachability, not just tidiness.
-
-**Rough shape (not yet built):** move the action icons + overflow menu into
-a bottom strip (title/back stay in the top bar). Auto-hide both the top and
-bottom strips together on scroll (hide on scroll-down, reveal on scroll-up
-or tap), matching the common "immersive reading" pattern other reader apps
-use. Needs to coexist with the existing scroll-vs-swipe gesture handling in
-ReaderScreen without reintroducing the jank/interception problems already
-fought through there.
+Swipe is now gone entirely (see "Bottom action strip" above), which removes
+one whole category of possible interference. Worth a fresh look at whether
+scrolling still feels jerky now that nothing above the WebView is doing any
+gesture detection at all -- if it still does, the cause is something else
+(WebView rendering/compositing itself, the emulator's software rendering
+not reflecting real-device feel, etc.), not gesture interception.