[Feature Request]: 'Open in Editor' button on post-game scan popup with auto-trimmed highlights

[DarrellVS]

Is your feature request related to a problem? Please describe.
When a game process closes, Goodbit automatically scans for newly captured clips and goodbit highlights, displaying a summary popup notification. If a user wants to quickly turn those highlights into a shareable reel, they currently have to open the editor, import the clips, and manually cut out all the dead space between key moments.

Describe the solution you'd like
I propose adding an "Open in Editor" button on the post-game scan popup that not only opens the editor, but immediately trims the timeline down to the detected highlights/goodbits.

Key Requirements:

• Direct Editor Launch: Clicking "Open in Editor" opens Goodbit and routes the user straight to the Timeline Editor view.
• Auto-Trimmed Highlights on Load: Instead of placing raw, full-length clips on the timeline, the editor should automatically trim/cut each clip down to its detected "goodbit" segments (e.g., keeping only the active windows around audio peaks, smart tags, or detected visual actions).
• Zero-Effort Montage Generation: Allows creators to go from closing a game directly into a clean, ready-to-export highlight montage in a single click.

Technical Implementation Notes (Vue/Router):

• Pass both the clip paths and their associated highlight time ranges (startOffset, endOffset) via route state or store parameters when navigating:
  router.push({ name: 'Editor', query: { sessionHighlights: JSON.stringify(highlights) } })
• In the Editor component, construct timeline clips bounded strictly by those highlight timestamps, stripping out non-highlight regions automatically.

Checklist:

• I have checked for similar existing feature requests.
• I am willing to help test this feature if implemented.

[DarrellVS]

Codebase notes

Read against the repository at 9f00f0d (3.4.3) while planning the 3.5.0 bundle. This issue was written without access to the source, so some of it describes a program that is not this one. Correcting it here so the implementation does not inherit the assumptions.

The route plumbing already exists and is simpler than proposed. The editor accepts ?clips=1,2,3 and loads them in order: loadClipsFromQuery() (EditorPage.vue:691-707) reads clips or clip, dedupes against loadedQueryKey, resolves each through getClip(id) and appends. Three callers already use it (useClipActions.ts:24, ClipsGrouped.vue:60, useBatchOperations.ts:337). Do not serialise highlight ranges through the URL: the editor can recompute them from the clip ids, they are cached by mtime, and a URL carrying JSON breaks when somebody bookmarks it.

The auto-trim also already exists. trimAllToHighlights() (EditorPage.vue:524-548) does exactly what is described. Plan is to reach it with a query flag, ?clips=1,2,3&cut=highlights, rather than making it automatic for every editor open, since somebody opening the editor from the library expects their clips whole.

The sweep writes no GoodBits, deliberately, so there are no stored marks to cut to: the measurement lands in the cache and only clip.suggestedCount persists. The editor must derive ranges the same way it does today, through useClipHighlights().

The hard part, which the issue does not mention: the card cannot be clicked. The overlay (src/main/services/clipToast.ts:453-485) has setIgnoreMouseEvents(true) (:474) swallowing every click, focusable: false (:469) with showInactive(), sandbox: true and no preload (:472); its content is a data:text/html URL driven one way from main via executeJavaScript, and there is zero IPC from that window back to main today. Every one of those is deliberate: nothing about that card may disturb a game.

So the work is four narrow undoings: selective click-through (setIgnoreMouseEvents(true, { forward: true }) plus a hover toggle, so only the button rectangle catches a press), keeping focusable: false if a non-focusable window still receives the click (must be tested over a real borderless-fullscreen game, and if it cannot work without focus the feature should not ship rather than the card becoming able to steal focus mid-firefight), one minimal preload exposing a single channel, and routing.

Routing is already solved. openIn(path) at src/main/index.ts:217-227 calls showWindow() (restores from minimised, creates the window if there is none) then sends app:navigate, deferring to did-finish-load when the window was just created. The tray already uses it. So the button is openIn('/editor?clips=' + ids.join(',')). sessionWatch.ts:254-331 already has the clip list in hand.

Two details: a clip with no confident highlight should go on whole rather than be dropped (76 of 174 clips in the reference library hold nothing the screen can name, and those are the ones most worth watching manually), and the auto-trim needs one undo snapshot before it or the first Ctrl+Z undoes one clip's trim and leaves the rest.

Rejected alternative for the channel: navigating to a goodbit:// sentinel and catching will-navigate. It would make the card's button indistinguishable from a deep link, which deeplink.ts treats as hostile input on purpose.

Highest-risk item in the release. If it slips, cut it rather than ship a card that can alt-tab somebody out of a match.

[DarrellVS]

Reverted in #44 on request. Reopened so the idea is not lost.