feat: parallelize wizcli scans across image targets

Summary

WizCLISuite.run() (posit-bakery/posit_bakery/plugins/builtin/wizcli/suite.py) runs subprocess.run(...) serially in a for loop — one wizcli scan per image target. Like hadolint, this is a plain cmd: list[str] subprocess call and a good fit for the tool-agnostic posit_bakery/parallel/ module (ParallelShellExecutor/ShellTask) introduced in #588.

Scope

• Port WizCLISuite.run() to build ShellTasks from self.wizcli_commands and dispatch through ParallelShellExecutor, following the pattern in plugins/builtin/dgoss/suite.py.
• Add a --jobs/-j flag to the wizcli scan command, matching the dgoss run --jobs convention.
• Preserve existing per-target report parsing (WizScanReport.load), verbose-conditional stderr capture, and error aggregation (BakeryWizCLIError, WIZCLI_EXIT_CODE_POLICY_VIOLATION handling) exactly as-is; only the dispatch mechanism changes.
• Update/extend the live progress table behavior to match dgoss.

Out of scope

• Changing wizcli scan policy or report contents.

Part of the investigation started in #584. See #588 for the reference implementation pattern (dgoss).

Start with posit_bakery/plugins/builtin/wizcli/suite.py and compare its run() flow with plugins/builtin/dgoss/suite.py; then read the posit_bakery/parallel/ module and the wizcli scan command entry point. Done means scans use the parallel executor with a --jobs/-j option, progress matches dgoss, and report parsing, stderr handling, and error aggregation remain unchanged.