[episodes] Harden episode-scoped loads after the wrong-episode fix

[frankrousseau]

Problem

• A remotely deleted episode sent its detail page to another episode, and its task pages or a stale link to either got a stand-in
• Late loadEdits, loadAssets and loadShots responses could land under the key of a newer load and keep the wrong episode on screen
• An entity deleted while its list was loading, or during its own refresh, came back as a ghost row
• A production switch while loadAssets awaited the episodes left its loading flag raised and froze the tab
• The topbar treated a list of two live-added episodes as loaded and bounced a valid direct link to all
• The playlist page rebuilt a playlist under all or main against a shot map a load had just emptied
• Breakdown skipped the column width reset when the production switched during the episodes fetch
• CLEAR_EDITS duplicated LOAD_EDITS_START, and the keyboard multi-select test of ComboboxOptions was dropped

Solution

• Send the detail and task pages of a lost episode to the episodes list, on live deletion and stale links
• Ignore edits, assets and shots responses whose recorded loading key changed meanwhile
• Fetch a live entity once the list load settled, and skip one removed during its refresh
• Drop an assets load whose production changed while it awaited the episodes
• Gate the topbar episode refetch on the store's isEpisodeListLoaded flag
• Await the shots load in flight under a pseudo-episode; keep Breakdown's production snapshot
• Reuse LOAD_EDITS_START in CLEAR_EDITS, restore the keyboard test

[NicoPennec]

There are two points to correct:

src/store/modules/assets.js · const marker = isPartial ? '#partial' : ''

The two markers were not equivalent: the in-flight dedup in loadAssets compares the whole key. Under the all or main pseudo-episode, the schedule loads without tasks and shared assets under P/all#partial, and the breakdown and concepts pages now record the same key. Opening the breakdown while the schedule load is still in flight makes it adopt that dataset, without tasks or shared assets, and nothing refetches. Before this change the keys differed, so the second load waited and then fetched its own. Narrow race, but a new one. I would keep #shared.

tests/unit/store/assets.spec.js · gives up when the production changed while it waited for the episodes

This test passes on main too: with no current episode and an empty episode list, loadAssets returns [] on the "no episode" path before it reaches the new guard. Setting rootGetters.currentEpisode in the dispatch stub, as the real loadEpisodes would, makes it fail without the guard: LOAD_ASSETS_START then gets committed for the production left.

[frankrousseau]

Both fixed: #shared restored with a regression test for the in-flight dedup (7b16332), and the guard test now resolves an episode in the stub so it fails without the guard (4c5a028).