Opening an item reads it, and the page's keys (#11)

selectEntry in the page calls markRead, so picking a row reads it. Natively
an item could be opened, read and left, and it stayed bold. With it comes
the detail that would have been missed by guessing: on the Unread tab the
item you were reading is dropped when you move on to the next one, not
whenever a refresh next comes along, so nothing vanishes from under the
pointer mid-click. A flag that does not save rolls back and says so, where
the page toasts.

The keys are Feedly's set, from player.ts: j n and k p, shift J and K, o m
s v, shift A, r, [, space, the arrows, g then a d p l or s, and ? for the
list of them. The pair window is the page's second and a half, and p and s
mean different things with and without a g in front, which they do there
too.

They are UIKeyCommand rather than SwiftUI's onKeyPress, which is iOS 17,
and they hang off the hosting controller rather than the controller that
owns it: SwiftUI's views hold first responder, so the chain starts inside
that hierarchy and an override further up is never consulted.

What is tested is the map, in KeysTests -- that p is Previous alone and
Popular after g, that every mapped key is registered, that the window is
1.5s -- because a wrong letter there loses a shortcut silently. What is not
tested is whether a press arrives at all: the simulator drops key events
unless something is focused, and running the same tests against Catalyst,
where the keyboard is the point, needs the runner to have accessibility
permission it does not have here. That test is skipped with the reason
written in it rather than deleted or left red.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

ios/UITests/PlaybackTests.swift

@@ -131,3 +131,18 @@ final class PageScreenTests: XCTestCase {
                       "the dialog is there but not the one expected")
     }
 }
+
+/// The page's keys, which are most of why a list is worth using on a Mac.
+///
+/// These are skipped rather than deleted, and it is worth saying why. Driving them needs key
+/// events to reach an app that is not focused on a text field, and the simulator drops those;
+/// running the same tests against Mac Catalyst, where the keyboard is the point, needs the test
+/// runner to have accessibility permission, which it does not have here. The mapping itself is
+/// covered by KeysTests, which is where a typo would silently lose a shortcut. What is left
+/// unproven is the wiring: whether the responder chain delivers a press at all.
+final class KeyboardTests: XCTestCase {
+    func testTheKeysAreDrivenByHand() throws {
+        throw XCTSkip("key events need a focused app the simulator will not give, and the "
+                      + "Catalyst runner needs accessibility permission; press ? in the app")
+    }
+}