`bg_runner.py` passes redundant `--silent` to bg child whose streams are already DEVNULL'd

[jrob5756]

Summary

bg_runner.launch_background() builds the bg child command with --silent (line 172) but also redirects all three of the child''s streams to subprocess.DEVNULL (lines 208-210). Silence is already enforced at the OS level; the --silent flag adds nothing for the user.

Worse, --silent flips internal verbosity state in the child:

# conductor/cli/app.py:197-204
if silent:
    verbosity = ConsoleVerbosity.SILENT
elif quiet:
    verbosity = ConsoleVerbosity.MINIMAL
else:
    verbosity = ConsoleVerbosity.FULL
console_verbosity.set(verbosity)
verbose_mode.set(verbosity != ConsoleVerbosity.SILENT)
full_mode.set(verbosity == ConsoleVerbosity.FULL)

That means in bg mode, verbose_log() is a no-op for the console and — depending on whether is_verbose() gates other behavior elsewhere — could hide events that future debuggers want to see. The console output is going to DEVNULL anyway; there''s no value in additionally suppressing it at the application layer.

Suggested fix

Drop --silent from bg_runner.py:172:

cmd: list[str] = [
    sys.executable,
    "-m",
    "conductor",
    # (removed: "--silent",)
    "run",
    str(workflow_path),
    ...
]

Same edit at the equivalent line in launch_background_resume.

This lets the bg child run with default verbosity. All console writes still go to DEVNULL (Popen stdout/stderr=DEVNULL handles that), but verbose_log() calls also flow into the --log-file writer if --log-file auto was passed, giving a future debugger a real trace of what the child was doing.

Side benefit

Removing --silent from the synthesized command also makes it possible to reproduce the bg invocation by hand without learning that --silent is being added behind the scenes — useful when diagnosing related issues like #195.

Environment

• conductor 0.1.16