pagination: KDoc and docs still reference removed/renamed types after the unification

[OmarAlJarrah]

Context

After #202 collapsed the two pagination stacks, several doc comments and reference docs still
describe the pre-unification API. Each item below is a self-contained accuracy fix.

Strategy contract KDoc says [Page], but parse returns PageInfo

PaginationStrategy.parse now returns PageInfo<T> (its @return correctly says so), but two
summaries still link the removed return type:

• PaginationStrategy.kt:14 — "Parses a [Response] into a [Page] ..."
• PaginationStrategy.kt:37 — "Parses [response] into a [Page] of items."

The KDoc contradicts itself ([Page] in the summary vs [PageInfo] in @return), and [Page]
is now a Closeable holding a live Response — precisely what a strategy must not return —
so the stale link is actively misleading. The same phrasing sits on both paginators'
@property strategy:

• Paginator.kt:81 — "Strategy that parses each response into a [Page]."
• AsyncPaginator.kt:121 — "Strategy that parses each response into a [Page]."

All four should read [PageInfo].

forEachPageAsync / byPage overstate raw-body availability

The KDoc promises the delivered page's "raw Response/body is open and readable for the
duration of the callback." Every shipped strategy drains the body inside parse(...) to
materialize items, and the body is single-use, so in practice only the response metadata
(status / headers) is readable on the delivered page — not the body. The wording should say so
rather than implying the body is replayable.

implementation-plan.md WU-9 lists the removed SimplePage as shipped

The supersede banner notes "SimplePage was removed," but the "Status: shipped" paragraph just
below it (line 379) still lists "helper types SimplePage and RequestRebuilder." Drop
SimplePage from that list so the section stops contradicting itself.

refs-comparison.md still lists a separate "token" strategy and a prev_cursor

The Pagination section was only partly updated (http.paging.PagedIterable →
pagination.PagedIterable) and still says:

• "driven by a PaginationStrategy (cursor, page-number, token, link-header)"
• "concrete impls covering cursor (next_cursor / prev_cursor), page-number, token, and
  link-header"

Only three strategies ship (Cursor / PageNumber / LinkHeader). There is no separate token
strategy — token-style APIs use CursorPaginationStrategy with a configurable query-param name,
as architecture.md already explains — and CursorPaginationStrategy is forward-only (no
prev_cursor; BiDirectionalPage is deferred). Align this section with architecture.md.

References

#202 (#30).