fix-findinglisted

# Fix Finding ## Objective Turn a current security finding into a minimal, validated code change. If the code is already safe, prove that and report that no change was needed. Judge the result in this order: 1. the current state is correctly classified as vulnerable, already safe, or unproven 2. any fix completely closes the broken security boundary 3. legitimate behavior and compatibility are preserved 4. relevant repository checks pass 5. the implementation follows repository conventions 6. the patch contains only the scope necessary for the earlier properties Never trade an earlier property for a later one. Minimal means the smallest repository-native change that satisfies all earlier properties, not the fewest lines. ## Patch Contract Before editing, inspect the affected implementation, its direct callers, nearby helpers, and relevant existing tests. Establish from repository evidence: - the attacker-controlled input and concrete source-to-sink path or broken control - the security invariant and narrowest shared enforcement boundary - legitimate behavior, APIs, error semantics, and compatibility constraints that must remain - the closest existing implementation, validation, and error-handling precedents Treat the finding as a data-flow and boundary problem, not merely the named input example. Check equivalent encodings, parser forms, aliases, callers, sinks, and every representation or copy of security-sensitive state that could bypass the proposed change. Handle