Design and implement wizcli scan-context-id strategy

[bschwedler]

PR #715 adds bakery wizcli scan but does not set --scan-context-id,
so Wiz falls back to its own default grouping for baseline comparison.

We need to design and implement a context-id scheme that groups scans
into stable per-artifact baselines (image, version/channel, OS, variant,
platform) without conflating unrelated builds or generating a new
baseline on every patch bump or rebuild.

An earlier draft in #715 (commits 54552bf, f8978da, a328320)
computed an ID like connect-2026-07-ubuntu-22-04-std-amd64 from image
name, release month (or dev channel), OS, variant, and platform, with
build metadata and Positron build-number suffixes stripped so patch
bumps update the same context in place. That logic was pulled out
before merge to keep #715 scoped to wiring the scan into CI; this
issue tracks getting the design and implementation right separately.

Scope:

• Decide the ID format for release, dev, and matrix versions
• Confirm how Wiz uses scan-context-id for baselining (repo + branch +
  ID) and what granularity avoids false positives/negatives
• Reinstate --scan-context-id in WizCLICommand, with an optional
  CLI passthrough for explicit overrides
• Tests

Related:

• Add wizcli security scan to bakery-build-native.yml #715
• Implement image security scans using wizcli #217

[bschwedler]

For reference, this is the implementation removed from PR #715 before merge:

@computed_field
@property
def default_scan_context_id(self) -> str:
    """Generate the default scan context ID for grouping related scans in Wiz.

    Context IDs identify one comparable artifact: image, release month (or dev
    channel), OS, variant, and platform. Wiz uses this ID to select a baseline,
    so different artifacts must not share one. Release and matrix versions use a
    month/minor-stripped version (e.g. ``connect-2026-07-ubuntu-22-04-std-amd64``,
    ``connect-content-r4-5-python3-14-amd64``) so patch bumps and build-number
    increments update the matching artifact in place. Dev builds use their
    channel in place of the release version. Build metadata (``+build.5``) is
    dropped and Positron build-number suffixes (e.g. ``-2`` in ``2026.08.1-2``)
    are stripped after strip_patch, both so the context stays at monthly
    granularity.
    """
    t = self.image_target
    if t.release_channel != ReleaseChannelEnum.RELEASE:
        version_or_channel = t.release_channel.value
    else:
        # Drop build metadata first: `+` survives both strip_patch and the
        # trailing-digit strip, so `2026.07.0+build.5` would otherwise reach the
        # final substitution and land as `-2026-07-build-5`, giving every build of
        # a `+meta` release its own context instead of updating one in place.
        version = t.image_version.name.split("+", 1)[0]
        version_or_channel = re.sub(r"-\d+$", "", strip_patch(version))
    tv = t.tag_template_values
    raw = "-".join(
        part
        for part in [
            t.image_name,
            version_or_channel,
            tv["OS"],
            tv["Variant"],
            self.platform_arch,
        ]
        if part
    )
    return re.sub(r"[ .+/]", "-", raw).lower()

It was wired in via cmd.extend(["--scan-context-id", self.scan_context_id or self.default_scan_context_id]), with scan_context_id as an optional
explicit override on WizCLICommand/CLI. Tests covering it are in the removed
diff on #715 (test_release_context_id_stays_stable_per_artifact,
test_scan_context_id_dev_uses_channel,
test_scan_context_id_omits_absent_dimensions,
test_scan_context_id_explicit_override).