import-progress events are broadcast to every window with no database/session id to distinguish concurrent imports #3002

Problem

No user or developer can hit this today — the app only ever has one window (single static window declared in tauri.conf.json plus a tauri-plugin-single-instance guard) and the only import UI (import-options-modal.svelte) serializes imports via a disabled button, so the scenario this finding describes cannot currently occur. It would need fixing before either a multi-window "open in new window" feature or a concurrent-import feature ships — and the original finding's framing ("unlike every other database-scoped event... which routes through emit_routed") is also inaccurate: several sibling files (chat_models.rs, local_agent.rs, agent_session.rs, pro_sync.rs) still emit database-scoped events via bare app.emit() too, so this is one of several not-yet-migrated call sites, not an outlier violating an otherwise-universal rule.

Root cause

import_markdown_file/import_markdown_files (packages/desktop-app/src-tauri/src/commands/import.rs:163, :230) call bare app.emit("import-progress", ImportProgressEvent{...}) instead of window_routing::emit_routed, and ImportProgressEvent carries no database_id/session id. window_routing.rs's own doc explicitly calls the multi-window trigger "any future 'open in a new window' trigger" — i.e. not yet implemented — and import_markdown_directory's promise doesn't resolve until the backend stream fully drains, so a second import can't start until the first finishes.

Suggested fix

Route these commands' progress events through window_routing::emit_routed (adding a database_id/session id to ImportProgressEvent) before any "open in a new window" or concurrent-import feature ships.

Found via the 2026-09-25 full-repo code sweep (finding #59 of 84 in CODE_SWEEP_FINDINGS_2026-09-25.md). Severity: low. Category: practical-ux.