Fix crash on blank-guid articles; simplify browser back; backlog notes

- FeedParser: a feed with a literal empty <guid>/<id> element (confirmed
  live: a Mother Jones entry) produced an ArticleEntity with id = "" --
  the fallback chain only checked for null, not blank, so an empty-but-
  present tag passed straight through. An empty-string primary key broke
  Navigation Compose's route matching and crashed on tap ("tapping this
  article crashes the app"). Fixed both RSS and Atom paths to treat blank
  the same as null before falling back to a link-based id. Schema v5
  migration deletes any row already on-device with the bad id; it'll
  come back with a real, hash-based id on the next fetch of that feed.
  Verified live: zero blank-id rows after the migration and a fresh
  fetch, no crash.

- BrowserScreen: back (both the system gesture and the in-app arrow) now
  always closes the screen directly, rather than stepping through
  in-page WebView history first. Reported live as not making sense for
  multi-page browsing (search results -> article -> another link, etc.)
  -- you'd have to tap back that many times just to leave. There's no
  separate in-page-back affordance now, matching how every other screen
  in this app behaves.

- Tried moving swipe-to-next-article detection off Compose's gesture
  system entirely (a passive native OnTouchListener on the WebView, never
  consuming) on the theory that Compose's gesture arbitration was the
  source of reported scroll jerkiness. Reverted after confirming live
  that swipe stopped working at all with that approach -- a worse
  regression than unproven jerkiness. Back to the known-working
  Compose-based detector; the jerkiness complaint itself is still open.

- BACKLOG.md: added bug-report-button, smaller-title-text, and
  bottom-action-strip-with-auto-hide notes.

1 files changed, 34 insertions, 0 deletions

diff --git a/BACKLOG.md b/BACKLOG.md
index 49f20d0..b36d66c 100644
--- a/BACKLOG.md
+++ b/BACKLOG.md
@@ -47,3 +47,37 @@ extracted or feed-provided HTML and swap it for a tap-to-play thumbnail
 (image + play button) that opens the video in the YouTube app/browser on
 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
+
+**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.
+
+**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.
+
+## Smaller title text
+
+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.
+
+## 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.