[Task]: Add repository Taskfile for common workflows

[rian-be]

Summary

Add repository Taskfile that standardizes the most common local and CI adjacent workflows for ModularityKit.Mutator.

Goal

Reduce command drift across the repo by giving contributors single, documented entrypoint for routine tasks such as build, test, formatting, and targeted test execution.

Problem

The repository already has multiple projects and test surfaces, and the number of repeatable commands is growing. Right now, contributors need to remember long dotnet invocations, project paths, and target specific switches. That makes common work slower, less consistent, and easier to get wrong.

A Taskfile gives the repo a stable command layer without introducing runtime behavior changes. It should be the preferred local wrapper for common workflows, especially where the same command line is repeated across multiple projects or test packages.

Scope

• Add a root Taskfile.yml or equivalent task definition for the repository
• Provide first class tasks for build and test workflows
• Provide targeted tasks for the major test packages already present in the repo
• Provide tasks for formatting or verification workflows used during local development
• Support optional task parameters where workflow naturally varies by project, package, or test filter
• Keep the task definitions thin wrappers around existing repo commands rather than introducing custom orchestration logic
• Document the available tasks and the expected usage pattern in repo facing docs

Design Expectations

• Task names should be short, explicit, and stable.
• Tasks should mirror real repo workflows, not invent a second abstraction layer over dotnet.
• The root task entrypoint should be easy to discover from the repository root.
• Provider-specific or package specific commands should remain visible as separate tasks rather than being hidden behind a single overly generic target.
• The task layer should stay maintainable as the repo grows, which means avoiding clever shell composition when a direct command is clearer.

Suggested Task Surface

• build
• test
• test:governance
• test:governance:redis
• test:core
• format
• clean
• restore
• docs or verify
• test:project <path> or equivalent parameterized task for focused runs

Acceptance Criteria

• A contributor can build the repo from the task entrypoint without memorizing the full solution command
• A contributor can run the main test packages through the task entrypoint without manually repeating project paths
• The task layer covers the workflows that are repeated most often in this repository
• The task file stays readable and does not become miniature scripting project
• Repo documentation points contributors to the task entrypoint for common local workflows

Non-Goals

• This issue does not change build or runtime behavior
• This issue does not replace dotnet or gh for direct use when needed
• This issue does not introduce general purpose automation framework beyond repository workflow tasks
• This issue does not require every niche command to be encoded as task if the usage is rare

Notes

This should be implemented in a way that matches the repo's existing style: direct, explicit, and low ceremony.