Design and implement wizcli scan-context-id strategy

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 54552bf5, f8978daa, a3283202)
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:

• https://github.com/posit-dev/images-shared/pull/715
• https://github.com/posit-dev/images-shared/issues/217

Start with PR #715 and the existing WizCLICommand implementation to understand how bakery wizcli scan is wired into CI. Verify Wiz scan-context-id baselining and compare the release, dev, and matrix cases described here. Done means a documented stable ID strategy, optional CLI override support, reinstated scan-context-id wiring, and tests covering the agreed cases.