Clean up test-to-requirement traceability across baselibs components

## Goal

Bring every baselibs component's test-to-requirement traceability to a state that actually supports the ISO 26262 / ASIL-B verification evidence the codebase relies on: every `comp_req` is verified by tests that genuinely exercise it, every test that claims to verify a requirement actually does, and the requirement text itself is accurate.

## Background

This started with the bitmanipulation component (#499), where linking its existing tests to their `comp_req` needs surfaced more than missing links: a bounds-safety requirement whose tests never asserted the "leave the value unmodified" behavior it mandates, and a requirement that claimed an unimplemented "set byte" capability with a return-type convention that didn't match the code. Both were fixed, along with splitting an overly broad requirement into two atomic ones. That work is the template for the tasks linked under this Epic.

## Scope

Each linked task scopes this same clean-up to one or a few components. The result should close genuine gaps without padding out test combinations that already share the same implementation path, and should reconcile with any context that already exists for that component (open PR review threads, architecture docs, requirements inspection checklists) rather than duplicating or contradicting it.

Example of a prompt to help with the tasks:

```
/requirements-management-skill Bring the component's requirement-to-test traceability
(C++ gtest and Rust unit tests anywhere under score//) to a state where:
- Every comp_req's normative text accurately reflects what's implemented: no requirement claims a
capability that doesn't exist, describes API mechanics instead of observable behavior, or bundles
multiple, independently testable capabilities under one ID that would be more atomic split apart.
- Any scope a requirement claims is actually reflected by
the tests covering it, in both directions: neither claimed-but-untested nor tested-but-unclaimed.
- Every requirement's coverage matches what's appropriate for its nature: functional requirements have
real test coverage, while structural/non-functional requirements correctly verified by inspection
are left alone rather than forced into a test that can't meaningfully exist.
- Every test either verifies a real comp_req or has a clear, deliberate reason not to.
- The result is neither under- nor over-tested: any change closes a genuine gap in observable behavior
rather than padding out combinations that already share the same implementation path.
- Nothing here contradicts or duplicates context that already exists: open PR review threads on this
component, its architecture doc, and its requirements inspection checklist, if any.

Report the current state against that bar, and check with me before any change beyond mechanical
metadata cleanup (rewording, splitting, or authoring a requirement; removing a test). Have an
independent sub-agent sanity-check the result against the skill's own linkage-review criteria.
```

Start by reading the linked component tasks, then inspect comp_req metadata and the C++ gtest and Rust unit tests under score//. Check the architecture doc, requirements inspection checklist, and any open PR review threads before changing anything. Done means each requirement and test has justified two-way traceability, accurate normative text, and appropriate functional or inspection-based verification without redundant coverage.

Written by the indexing model from the issue text.