Diary: a first-batch load failure offers no retry affordance (footer is gated on entries.length > 0)

[steilerDev]

[product-architect] Filed as a deferral from the PR #2063 review (Issue #2060, diary infinite scroll).

Problem

DiaryPage renders InfiniteScrollFooter only when entries.length > 0:

{entries.length > 0 && (
  <InfiniteScrollFooter status={status} ... onRetry={retry} />
)}

The footer is the only host of the retry control. So when the first batch fails, useInfiniteScroll
sets status === 'error' but no footer — and therefore no retry button — is rendered. The user sees only
the page-level shared.bannerError banner, which is static text.

Recovery from a first-batch failure is then impossible without either a full page reload or changing a
filter (which bumps resetKey and re-fetches as a side effect). Notably loadMore() also no-ops in the
error state by design, so the IntersectionObserver cannot recover it either.

Why this is a deferral, not a PR #2063 blocker

• Not a regression. beta's DiaryPage had no retry affordance for a failed diary fetch either
  ({error && <div className={shared.bannerError}>{error}</div>} and nothing else). PR feat(diary): replace numbered pager with infinite scroll #2063 strictly
  improves error handling by adding footer-level error + retry for subsequent batches.
• Not covered by an AC. Diary: replace the broken numbered pager with scroll-driven batch loading #2060's AC 13/14 are both scoped to "Given one or more batches are loaded" —
  the first-batch case is outside the accepted scope of that story.
• Fixing it properly is a small design decision (does the page-level banner grow a retry button, or does
  the footer render on status === 'error' even with zero entries?), not a mechanical edit, so it does not
  belong in a fix loop on an otherwise-complete PR.

Suggested direction (not prescriptive)

Either:

1. Render InfiniteScrollFooter when entries.length > 0 || status === 'error', letting the existing
   footer error + retry cover the first-batch case too (and drop or demote the page-level banner so the
   error is not stated twice); or
2. Give the page-level bannerError its own retry button wired to retry().

Option 1 keeps a single error/retry code path and is likely cheaper, but needs a UX call on the
double-error-message question. Either way the fix is client-only — no API, schema, or hook change.

Acceptance sketch

• Given the first diary batch request fails, When I look at the page, Then an error message with a
  keyboard-reachable retry action is shown, and activating it re-requests page 1.
• Given the retry succeeds, Then the first batch renders normally and no error remains on screen.
• The error is stated once, not twice.