Normalize ZnSymmetry outputs into valid qnums

[yingjerkao]

Fixes #766.

Summary

• normalize ZnSymmetry scalar and vector combine_rule outputs into [0, n)
• normalize reverse_rule output so public results satisfy check_qnum
• remove the signed-modulo behavior that could produce -1 for Z2 and other invalid values on reverse
• add a public API regression for Symmetry::Zn(2) covering both combine and reverse paths

Verification

• ./build/openblas-cpu/tests/test_main --gtest_filter="Bond.ZnSymmetryNormalizesPublicRules"
• ./build/openblas-cpu/tests/test_main --gtest_filter="Bond.InitWithQnum_v2:Bond.CombindBondSymm_v2:Bond.ZnSymmetryNormalizesPublicRules"

[codecov]

Codecov Report

❌ Patch coverage is 77.77778% with 2 lines in your changes missing coverage. Please review.
✅ Project coverage is 35.49%. Comparing base (a22dd1e) to head (896d732).
⚠️ Report is 16 commits behind head on master.

Files with missing lines	Patch %	Lines
src/Symmetry.cpp	77.77%	2 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #768      +/-   ##
==========================================
+ Coverage   35.47%   35.49%   +0.02%     
==========================================
  Files         214      214              
  Lines       33007    32998       -9     
  Branches    13130    13132       +2     
==========================================
+ Hits        11709    11714       +5     
+ Misses      19376    19361      -15     
- Partials     1922     1923       +1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[ianmccul]

I can't see anything obviously wrong with the PR, but just a question of the semantic meaning of a Zn quantum number. The current code allows numbers outside the range [0,n) but normalizes outputs to that range with the modulo function. If I was designing this I would make numbers outside the range [0,n) erroneous and an error if it is passed into a function expecting a Zn quantum number.

[yingjerkao]

@ianmccul The current codebase semantics are mixed here: check_qnum and Bond construction treat valid Zn qnums as canonical values in [0, n), but the public arithmetic API (combine_rule / reverse_rule) has historically accepted wider integer inputs and computed on them instead of rejecting them first. This PR keeps scope to restoring the invariant that those public arithmetic functions return canonical Zn outputs in [0, n), because that is the correctness bug affecting existing behavior. Tightening the API to reject out-of-range Zn inputs is a broader policy change and would be better handled separately so we can decide compatibility and call-site impact explicitly.