Route context-menu captures through chrome.downloads so they resolve
Chrome's real filename (Content-Disposition, extension, etc.) via the
same onDeterminingFilename path auto-capture already uses, and harden
the native host against the bare-directory destDir KGet was misparsing
as a filename.
Ctrl+S on a page you navigated to directly via file:// is still a
"download" as far as chrome.downloads is concerned, so auto-capture
was intercepting it and handing the local path to KGet, which
rejects it with a confusing "protocol is not supported" dialog since
it's a network download manager, not a file copier. Extend the
existing blob:/data: exclusion to also cover file:/filesystem:, and
apply the same guard to the right-click capture path.
Switch auto-capture from onCreated to onDeterminingFilename, which
fires once Chrome has already resolved the real filename (from
Content-Disposition or the URL). That name is now passed through to
the native host and used to build a full dir+filename destination for
addTransfer, replacing showNewTransferDialog. A non-empty destDir
makes KGet skip its interactive dialog and start immediately, which
also fixes it showing an opaque URL path segment as the filename for
signed/obfuscated URLs (e.g. cloud storage links) instead of the real
name.
Also enable KGet's existing (but disabled-by-default) "Download
Finished" KNotify popup via install.sh, so there's still feedback now
that captures no longer show an interactive dialog.
andwati