fix: add creationflags to vision_tools SVG-to-PNG subprocess calls

[AlexFucuson9]

Summary

On Windows, subprocess.run() without CREATE_NO_WINDOW (0x08000000) spawns a visible console window. tools/vision_tools.py has two SVG-to-PNG conversion calls (rsvg-convert and inkscape) missing this flag. Both calls have stdin=DEVNULL and capture_output=True, so they are non-interactive.

Fix

Add creationflags=0x08000000 on Windows. sys is already imported at module level.

Changes

• tools/vision_tools.py: +1 line

Test Plan

• Unit tests pass
• Verified on Windows: no console flash on SVG-to-PNG conversion

[teknium1]

Thanks for identifying this Windows-specific subprocess path. Current main still reaches tools/vision_tools.py:292-295 without creationflags, and the single shared call serves both rsvg-convert and inkscape, so the proposed guard fixes the stated path.

Suggested changes

• Add a focused regression test for _rasterize_svg_to_png() that captures the system-rasterizer spawn and asserts the Windows no-window flag. Existing Windows subprocess coverage follows this pattern in tests/test_windows_subprocess_no_window_flags.py:304-320.
• Prefer windows_hide_flags() from hermes_cli._subprocess_compat to the inline literal. That helper is explicitly for synchronous output-capturing children (hermes_cli/_subprocess_compat.py:186-201) and is already used for comparable tool conversions in tools/tts_tool.py:1932.

This is an automated hermes-sweeper review.

[teknium1]

Suggestion: use windows_hide_flags() here instead of duplicating 0x08000000. It is the shared helper for short-lived synchronous subprocesses with captured output and returns 0 on non-Windows (hermes_cli/_subprocess_compat.py:186-201).

[teknium1]

Closing after the class-level fix in PR #70205 (commit 0dbf639): Windows console flashes were caused by Hermes daemons running console-less (pythonw / DETACHED_PROCESS parents), forcing every console-subsystem child to allocate its own visible window. Main now launches every daemon (gateway, Scheduled Task, UAC handoff, dashboard, desktop backend) with a hidden console that all descendants inherit — so the spawn sites this PR flags no longer have a reachable flash under any shipped launch path (interactive terminals never flashed; children inherit the visible console there).

The sites you patched were genuinely unflagged, and the diagnosis was sound against the old launch topology — the ground just moved under it. Rather than keep growing per-site flags across an unbounded set of leaf spawns, we're standardizing on the parent-console fix. If a flash reappears on current main under a shipped launch path, that's a new bug — please file it with the flashing process name.

Thanks for the contribution and the Windows attention; sorry this one got mooted at the root.