perf(notifications): use conditional requests for the notifications list

[joshfree]

Fixes part of #3101 (Improvement 2 of 3).

Problem

The notifications list is requested with caching disabled and no validators
(listNotificationsForAuthenticatedUser in client.ts sets
Cache-Control: no-cache), so the full list body is transferred and re-parsed
on every poll even when nothing has changed.

Change

Cache the previous notifications-list response per account and send conditional
request validators (If-None-Match from the stored ETag, falling back to
If-Modified-Since from Last-Modified). When GitHub responds 304 Not Modified, the cached list is returned without transferring or re-parsing the
body. A 304 also does not count against the primary rate limit.

Notes:

• Octokit throws a RequestError with status === 304 for an unchanged
  conditional request, so that is caught and mapped back to the cached list.
• Cache-Control: no-cache is retained to force revalidation rather than serve
  a stale locally-cached response; the validators are added alongside it.
• The paginated ("fetch all") path captures the validators from the first page.

Tests

Added coverage in client.test.ts for: replaying the stored ETag as
If-None-Match on the next poll, and returning the cached list on a 304 for
both the single-page and paginated paths.

[setchy]

i have a feeling the explicit no-cache on this api route was due to this user-flow

#3102 (comment)
There was also some interesting notification timestamp behavior as notifications go from your unread inbox, to done/read, to being manually moved back to your inbox - so we'd need to go ensure our cache key handles this, too

we'll need to test how this PR handles situations like this