Implement the library query surface a client needs to show a first screen

[iderex]

This is the smallest set of reads that lets a client draw something real, and it
is what the first release in M11 exercises end to end.

What this produces

The user's views. The items in a view, paged, sorted and filtered, with the
paging shape decided here rather than per caller.

Resume, which is the first screen on a television.

NEXT UP IS NOT IN THIS ISSUE, DECIDED 2026-08-30, AND THIS LINE NAMED BOTH.
0010 is the authority for which paths the core may reach and its table has a
row for resume and none for next up. Adding one to keep a route inside a
first-screen issue inverts the order this tree works in: the surface record
decides, then the feature issue builds to it. The route is not lost - it is
#272, argued on its own merits as a record that supersedes 0010, where a reader
can see what the table gained and why. 0039 already fixes what next up is not,
so what is open there is the route rather than the shape of the answer.

One item in full detail.

Everything above returning the same item type, so that a client written against
one call can display the result of another.

Done when

Each call has a test against a recorded fixture, paging is proven across a
boundary rather than only within one page, and the item type is identical across
all of them. The calls are the views, the items in a view, one item in full, and
resume; next up is #272 and is not one of them.

The three issues this body named as blockers are closed. What every condition
above still needs is a request having been made and a recording of one, and the
comment of 2026-08-30 on this issue is where both readings are; neither is
repeated here.

[iderex]

A record that landed after this issue was written hands it a question, and the
list above has no line for it. Read at
e4903a96a909ea5d2a1300b9a04100e3a461911a.

sed -n '76,81p' docs/decisions/0116-learning-that-something-cached-has-changed.md
What it does not buy is a route by which the core wakes a client. Nothing here
pushes anything upward. The core marks its own cache and a client learns on its
next read, which is what this issue's own condition asks for and is 0043's
stale-then-fresh path arriving sooner. Whether the core offers a client a signal
that something moved is a question about the query surface in #39 and is not
decided here.

Two things follow, and they are different sizes.

The smaller one is the question 0116 names. Whether a client is offered a signal
that something moved, rather than finding out by reading again, is a decision
about this surface and it is deferred here rather than settled anywhere.

The larger one is that the sentence before it is a requirement rather than a
deferral. A client learns on its next read, which means these calls are the route
by which an invalidation becomes visible to a client at all. The list above
describes four reads and the item type they share, and it says nothing about what
a read carries when the entry behind it was marked. That is the same property
0043 hands a reader with every answer, and a surface written without it makes
0116's whole route end at a cache nobody can observe from outside.

The paging shape is where it is most likely to be missed. A read that answers a
page is answering out of entries that may have been marked between two pages, and
what the caller is told about that has to be the same statement for page one and
page four or the property is not there at all.

I have changed no condition and no scope. The three conditions here are untouched.