[Task]: Add CI matrix for examples and test packages

[rian-be]

Summary

Add CI matrix that exercises the repository's major example projects and test packages as separate, explicit jobs.

Goal

Make CI coverage reflect the repository structure more accurately by running focused jobs for core tests, governance tests, Redis tests, and example scenarios instead of relying only on broad solution-wide validation.

Problem

The repository now contains multiple distinct surfaces:

• core runtime tests
• governance request and execution tests
• Redis provider tests
• example projects that act as executable documentation

A single coarse CI run hides which package failed, makes logs harder to scan, and increases the chance that a change breaks one area without clearly surfacing the affected surface. As the repository grows, that becomes a real maintenance cost.

A matrix based pipeline gives each major area a named job so failures are easier to understand and the workflow is easier to extend when new packages or example suites appear.

Scope

• Add CI workflow matrix for the major test packages in the repository
• Add separate jobs for ModularityKit.Mutator.Tests, ModularityKit.Mutator.Governance.Tests, and ModularityKit.Mutator.Governance.Redis.Tests
• Add example coverage jobs for the executable samples under Examples/Core and Examples/Governance
• Keep the matrix focused on build and test verification rather than release packaging
• Make job names clearly reflect the package or example group being validated
• Ensure the workflow remains maintainable as new packages or example projects are added
• Keep the workflow compatible with the repository's current .NET 10 solution layout

Design Expectations

• The matrix should make it obvious which repo surface failed.
• Jobs should be explicit about the project or package they validate.
• The workflow should prefer direct project/test commands over a generic monolithic script.
• Example jobs should verify that the samples still compile and run through their intended scenario entrypoints where applicable.
• The workflow should remain simple enough that adding a new package is a small, local edit.

Suggested Matrix Surface

• build
• test:core
• test:governance
• test:governance-redis
• examples:core
• examples:governance

Acceptance Criteria

• CI exposes separate validation jobs for the major test packages
• Example projects are validated in their own explicit job group
• Failed jobs identify the affected package or example group without ambiguity
• The workflow remains readable and does not collapse all work into one opaque build step
• The matrix is documented or discoverable from the repository's workflow files

Non Goals

• This issue does not change runtime behavior
• This issue does not introduce release signing or packaging automation
• This issue does not replace local developer commands or the Taskfile issue
• This issue does not require every tiny scenario to become its own CI job

Notes

This issue is meant to follow the repository's package boundaries rather than obscure them. If a package or example group has its own dedicated concerns, the CI job should make that clear.