string_manipulation: define requirements and clean up test-to-requirement traceability

The String Manipulation facility moved from `score/memory` to `score/string_manipulation` in July 2026. The old Memory targets are deprecated forwarding shims, but `comp_req__memory__string_utils` and the Memory architecture still allocate the former implementation to Memory.

Define the String Manipulation component documentation, architecture, and component requirements for the current owned APIs: `LazySplitStringView`, `StringComparisonAdaptor`, and `GetArguments`. Do not mechanically relocate or rename `comp_req__memory__string_utils`: its `memory_library` upstream derivation and its broad zero-allocation claim do not accurately apply to the relocated APIs. Establish appropriate upstream traceability before authoring the new requirements. The deprecated `StringLiteral` alias must not receive a new functional requirement.

Then apply the #522 test-to-requirement traceability cleanup to every C++ gtest under `score/string_manipulation/`: link tests only to the new `comp_req__string_manipulation__...` needs they genuinely verify, and record mandated `FullyVerifies` or `PartiallyVerifies`, `TestType`, `DerivationTechnique`, and self-contained `Description` metadata. Do not create artificial test coverage for inspection-only requirements.

Start by inspecting the current component documentation, architecture, and requirements under score/string_manipulation/, then compare the deprecated score/memory forwarding shims and comp_req__memory__string_utils. Review every C++ gtest under score/string_manipulation/ and the traceability expectations from #522. Done means new requirements have accurate upstream traceability and all applicable tests carry the required metadata without artificial coverage.

Written by the indexing model from the issue text.