fix(review): list commit scopes newest first and keep the newest on huge prs

[xieziyu]

What

• The review-screen scope switcher and the entry-screen scope picker list commits newest to oldest. Alt-Up/Down follow the same row order. The chip's k/N still counts oldest to newest, matching the position the agent is told in the first-round prompt.
• The commit list now comes from GraphQL, paging backwards from the newest commit. The REST pulls/N/commits endpoint only ever returns the oldest 250, so on PRs with hundreds of commits the ones people look for were exactly the ones cut off. Truncation now drops the oldest, the total is exact, and the pinned commit's ordinal accounts for the cut-off ones.
• The container's commit list is cached in memory with a 60s TTL and dropped on rerun or delete, so reopening the menu only recomputes local scan states instead of hitting gh again.
• The scope menu scrolls its keyboard cursor into view on long lists.

Why

Newest-first is what people reach for when switching scope; old-to-new pushed the recent commits to the bottom of the list. Once the list was reversed, the REST cap dropping the newest commits became the worst possible truncation direction.

Verification

• typecheck, eslint pass.
• spike:scope extended: fake gh pages the GraphQL connection for real; covers cache hit/miss and a 260-commit PR (250 returned, oldest 10 dropped, pinned ordinal 11/260, pinned-outside-list falls back to compare).
• Real API: 2026-08-26, Version 26.8.0 (Current) nodejs/node#65551 (344 commits) returns the newest 250, tail matches a direct query.
• Preview: cursor stays in view stepping through a shrunken list; reopening scrolls to the current commit.