Fix Fetch Feed Automatically never fetching feeds of profiles other than the first one viewed

[VictorVow]

Pull Request Type

• Bugfix
• Feature Implementation
• Documentation
• Other

Related issue

Closes #6089

Description

The Fetch Feed Automatically setting is described as fetching the subscription feed "on startup and when a new window is opened". Since #5743 (first shipped in v0.22.0, which matches the "Last Known Working Version: v0.21.0" in the linked issue), the flag tracking whether the first automatic fetch has already run is a single boolean per window. The consequence: only the profile you view first ever gets an automatic fetch. When you switch to another profile, the flag is already consumed, so that profile silently shows whatever is in the persistent disk cache (which can be days old) and its feed is never automatically fetched at all during that session.

The issue was closed with the reasoning that showing cached results is intended, but I believe that misses what's actually going wrong. This is not about wanting a re-fetch on every profile switch - the problem is that for every profile except the first one, the automatic fetch promised by the setting never happens, not even once. If a profile's feed is never fetched automatically, then Fetch Feed Automatically simply isn't doing what its name and tooltip promise for that profile, and it's a regression from v0.21.0 where each profile got one automatic fetch per session.

This PR scopes the "first auto-fetch has run" tracking per profile (a Set of profile ids per tab type, instead of a boolean). Each profile now receives exactly one automatic remote fetch per session, the first time its feed is viewed. It deliberately does not re-fetch on every switch: returning to an already-fetched profile still shows the session cache, so the caching behaviour is preserved and there are no additional network requests compared to v0.21.0.

The one-time-fetch check was also moved above the cache-presence check in loadVideosFromCacheSometimes / loadPostsFromCacheSometimes, mirroring what #5743 did for the new-window path - otherwise the persistent disk cache would again take priority over the first automatic fetch.

Screenshots

N/A - no visual changes.

Testing

1. Create two profiles (A and B) subscribed to different channels.

2. Enable Settings > Subscription Settings > Fetch Feed Automatically.

3. Restart FreeTube with profile A active and open the Subscriptions page: the feed is fetched from remote as before.

4. Switch to profile B:

   • Without this PR: the page shows the stale feed from the disk cache and no fetch happens; B's feed is never fetched automatically for the rest of the session.

   • With this PR: B's feed is fetched from remote once.

5. Switch back to profile A, then to B again: both load instantly from the session cache - no re-fetching on subsequent switches.

6. Repeat on the Shorts, Live and Posts tabs; each tab tracks its first fetch per profile independently.

[efb4f5ff-1298-471a-8973-3d47447115dc]

• doesnt this close your own issue [Feature Request]: Fetch feed automatically for each profile setting #7262?
• Also should the tooltip description be changed to clarify behavior?

[PikachuEXE]

I would not consider this as a "fix" as the tooltip clearly indicates that it only does that on startup and new window (or just new window coz one is created on start up)

I am not rejecting this PR but its type is a feature change (improvement) and we generally review/test feature changes longer than fixes (well the small ones)

I think the Testing section needs to include all sorts of profile overlap types instead of the current one (A & B got some overlap only) first so we can test the changes

e.g. When profile A includes B but not reverse (A: ch 1,2 + B: ch 1)
Switching profile would re-fetch ch 1 and that doesn't seem right to me (worse when some profiles got a lot of overlaps)