Fix #164: rebind spans after copy/move/assignment

[jungdaesuh]

Summary

Fixes Issue #164: FourierGeometry/FourierVelocity/FourierForces store std::span views into FourierCoeffs-owned vectors. The compiler-generated copy/move semantics shallow-copy those spans, so after a copy the spans can still point at the source object's buffers.

This PR implements copy/move constructors and copy/move assignment operators for:

• FourierGeometry
• FourierVelocity
• FourierForces

These operations rebind the span members to the destination object's own storage after copy/move/assignment.

It also adds copy/move assignment operators to FourierCoeffs (const config members delete the implicit operator=).

Testing

• bazel test --test_output=errors --nocache_test_results //vmecpp_large_cpp_tests/vmec/fourier_geometry:fourier_geometry_test
• bazel test --test_output=errors --nocache_test_results //vmecpp/...

Limitations / follow-up

• FourierCoeffs keeps config as const refs/ints (Sizes/RadialPartitioning/ns*), so FourierCoeffs::operator= copies/moves only coefficient vectors and does not update config. Assignment is intended only between same-config objects; cross-config assignment is unsupported/undefined.
• Follow-up idea (API-breaking for C++): rule-of-zero value semantics by storing needed config scalars by value and replacing stored span members with span-returning accessors.

[jurasic-pf]

Thanks for looking into this issue.
Could you demonstrate that the copy+move semantics are now working as expected in a test case please? It looks good on first review though, please just split the changes related to the copy move issue and type checking improvements into separate PRs.

[jungdaesuh]

@jurasic-pf Thanks for the review. I will reply to specific comments once I sorted things out. It's like solving one issue keeps leading to another issue.

[jurasic-pf]

Great! Thanks for taking the time, I just added a test to confirm behavior is as expected.

[jungdaesuh]

Hi @jurasic-pf, sorry for the slow progress. I picked up #164 to make contributions to this repo and went with the minimal fix (rebind spans after copy/move/assignment). In hindsight I should have asked direction first.

If useful, I can follow up with a separate PR to:

1. add a focused in-repo copy/move semantics test, (I have it on my local, and was about to push it)
2. Or, pivot to accessor-based views (rule-of-zero design)

• (Initially considered 'delete copy/move for now' too)

Which direction do you prefer? I am happy to pick up other issues if you guys need extra hands. I would like to contribute.

[jungdaesuh]

@jurasic-pf I see that you've also added the test. Thank you!

[jungdaesuh]

@jurasic-pf I can't work on this full time, but would like to make contributions to this repo. I'll try to be more consistent.