perf(calendar): revalidate the cached events feed with conditional requests

[m1ngsama]

Every launch re-downloaded the full 87 KB events feed even when nothing had changed.

• The feed's ETag and Last-Modified are stored next to the cached feed (same directory, 0600) and sent with the next request through @nbtca/nbtcal 0.4.3.
• On 304 the calendar already parsed from the cache is reused without re-parsing; on 200 both files are replaced. Corrupt or missing metadata means an unconditional request, so a stale cache can never be pinned by a 304.
• Against a local server with ETag support, the second launch transfers 235 bytes instead of 87,294. The live feed starts answering 304 once perf: compress the feed and answer unchanged requests with 304 calendar#6 ships its ETag; until then requests behave as today.
• The offline fallback is unchanged.