Support downloading Instagram highlights

[jamditis]

v1.2 added active-story downloads (via reels_media). Highlights (/stories/highlights/<highlight_id>/) are a separate, permanent collection served by a different API, so they are out of v1.2 scope.

As of commit (this PR), extractStoryRef returns null for /stories/highlights/... so a highlight page no longer misroutes to a wrong-account story lookup — it falls back to the generic/DOM resolver, which may grab the visible frame but does not enumerate the highlight.

For v1.3: resolve a highlight by its id through the highlights reel API (reels_media with reel_ids=highlight:<id>, or the highlights tray endpoint), enumerate its items like the story tray, and add tests.

[jamditis]

Traced this against current master to find where the seam actually is. Most of the work is already built — highlights differ from active stories in exactly one place, and it is not the parsing.

What already works unchanged

parseStoryTray (src/platforms/instagram-api.js:108) reads apiJson?.reels_media?.[0]?.items. The highlights response has the same envelope, so enumeration, the storyId single-item filter, and item mapping need no changes at all.

resolveInstagramStories (src/background.js:628) already owns the fetch, the x-ig-app-id header, credentials: 'include', mapIgStatusToMessage error mapping, the aged-out empty case, and the debug tracing. All of that is identical for highlights.

The one real difference

const userId = await fetchInstagramUserId(username);   // <- highlights skip this entirely
const resp = await fetch(`.../reels_media/?reel_ids=${userId}`);

A highlight is addressed as reel_ids=highlight:<id>, and the id is already in the URL, so the username -> userId lookup is not just unnecessary, it is a failure mode: it is the network call most likely to 401 when logged out, and highlights would be blocked by a lookup they never needed.

Decomposition

1. Extract the reel-id seam. Split the body of resolveInstagramStories into a resolveReelsMedia(reelId, { storyId }) that does fetch -> parse -> error-map -> trace. Stories pass userId; highlights pass highlight:<id>. Everything shared stays shared, and the diff is a move rather than a rewrite.
2. Add extractHighlightRef(pathname) beside extractStoryRef (instagram-api.js:96). That function already returns null for /stories/highlights/... as a deliberate guard, with a comment explaining why — the new function is the other half of that guard, so keep them adjacent and cross-reference them.
3. Branch in the click handler (background.js, next to the existing extractStoryRef branch): highlight ref -> resolveReelsMedia('highlight:' + id, ...).
4. Tests: extractHighlightRef path parsing (with and without a trailing item id), and a parseStoryTray case against a highlight-shaped fixture proving the envelope assumption in step 1 holds.

Two things to confirm before building, not assume

• Whether the single-item URL form (/stories/highlights/<id>/<item_id>/) puts the item id where extractStoryRef expects it. Step 2's tests should pin whichever it is.
• Whether reels_media accepts highlight:<id> for a logged-out session or requires auth. That decides whether this ships as a normal path or needs the same login-required message stories use.

Sequence: step 1 is a pure refactor and can land on its own with the existing story tests as the safety net, which keeps the highlight feature diff small.

Receipt: wake-20260721T1305-d86279