Migrate sanitizer features from `score_bazel_cpp_toolchains` to `score_cpp_policies`.

[nradakovic]

Summary

Move sanitizer-related feature definitions and policy ownership from score_bazel_cpp_toolchains to score_cpp_policies.

Today, sanitizer support is already closely related to reusable C/C++ quality policy. It should be owned by score_cpp_policies rather than by the toolchain module so sanitizer behavior can be defined once, validated centrally, and reused consistently across repositories and toolchains.

Problem

Sanitizer support is currently tied too closely to the toolchain layer. That creates several problems:

• Sanitizer policy is not owned in the central policy module.
• Reusable quality-related behavior is split across repositories.
• Downstream users need toolchain-specific knowledge to adopt or adjust sanitizer behavior.
• Evolving sanitizer configuration, suppressions, and feature semantics requires changes in the toolchain repository rather than in the policy repository.
• Integration boundaries between toolchain implementation and policy definition are less clear than they should be.

Goal

Establish score_cpp_policies as the single source of truth for sanitizer feature definitions, sanitizer runtime policy, and consumer-facing sanitizer integration guidance, while keeping score_bazel_cpp_toolchains focused on toolchain integration.

Scope

This epic covers the migration of sanitizer-related functionality from score_bazel_cpp_toolchains to score_cpp_policies, including:

• sanitizer Bazel feature definitions
• sanitizer-related policy wiring exposed to consumers
• sanitizer configuration ownership
• sanitizer-related validation and test coverage
• consumer documentation and migration guidance
• downstream integration updates where needed

This epic does not cover unrelated compiler warning policy migration work except where there is shared migration or integration impact.

Expected Outcome

After this migration:

• score_cpp_policies owns sanitizer feature definitions and sanitizer policy.
• score_bazel_cpp_toolchains consumes sanitizer features from score_cpp_policies instead of defining them locally.
• Downstream users adopt sanitizer behavior through the policy module rather than through toolchain-specific implementation details.
• Documentation, tests, and integration examples reflect the new ownership model.
• Existing users have a documented migration path.

Proposed Approach

1. Identify all sanitizer-related features, flags, wrappers, suppressions, and integration points currently owned or exposed via score_bazel_cpp_toolchains.
2. Define the canonical sanitizer feature surface in score_cpp_policies.
3. Add validation coverage to ensure sanitizer features behave correctly after migration.
4. Update score_bazel_cpp_toolchains to consume the policy-owned sanitizer features.
5. Update downstream integration and reference setups.
6. Publish migration guidance and communicate rollout expectations to consuming groups.

Deliverables

• Sanitizer feature ownership moved to score_cpp_policies
• Toolchain integration updated in score_bazel_cpp_toolchains
• Validation and test coverage for sanitizer behavior
• Updated module documentation
• Migration documentation for downstream users
• Reference integration proving downstream consumption

Acceptance Criteria

• Sanitizer features are defined and owned in score_cpp_policies.
• score_bazel_cpp_toolchains no longer serves as the primary owner of sanitizer feature definitions.
• Existing sanitizer use cases continue to work through the migrated integration model.
• Test coverage exists for the migrated sanitizer behavior.
• Documentation clearly explains usage and migration.
• At least one downstream or reference integration validates the migrated setup.

Risks / Open Questions which should be mitigated / covered by migration documentation.

• Some downstream users may rely on current toolchain-specific sanitizer behavior implicitly.
• Migration may expose unclear ownership boundaries between toolchain wiring and policy configuration.
• Compatibility expectations for existing feature names and activation patterns need to be confirmed early.
• Cross-toolchain behavior should be checked to ensure the policy model remains reusable.

Follow-up Issues

Child issues should be created for (tasks will be created shortly):

• defining sanitizer features in score_cpp_policies
• adding validation or unit/integration tests
• updating module documentation
• writing and presenting migration guidance
• integrating the migrated sanitizer features into reference downstream setups