Add Basilisk detumble migration baseline

[jtran34-ctrl]

Summary

Adds a Basilisk-based ADCS detumble migration baseline.

This PR starts the migration from the standalone C++ ADCS/WMM simulation into a fast Basilisk workflow. It uses pip-installed Basilisk as the simulation dependency and avoids rebuilding Basilisk for normal controller/script updates.

What is included

• Adds Basilisk runner scripts:
  • scenario_huskysat2_minimal.py
  • scenario_huskysat2_detumble.py
  • scenario_huskysat2_pointing.py scaffold
• Adds plotting and comparison utilities.
• Adds a lightweight cpp_adcs_core/ scaffold for future standalone controller logic and optional Python bindings.
• Preserves the standalone C++ simulation under reference_standalone/original_project/.
• Adds migration documentation:
  • Basilisk capability audit
  • migration plan
  • interface contract
  • validation plan
  • build workflow
  • source inspection report
• Adds VS Code tasks for common workflows.

Validation status

Confirmed locally:

• pip-installed Basilisk works in the project virtual environment.
• Minimal Basilisk spacecraft propagation runs.
• Magnetic-field logging runs.
• Detumble scenario runs using direct magnetic torque application.
• Metric-based comparison pipeline runs.
• Generated outputs are finite.

Current detumble result:

• Initial angular speed: 0.877496438739 rad/s
• Final angular speed: 0.012723360738 rad/s
• Mean applied magnetic torque: 2.825e-06 N m
• Peak applied magnetic torque: 2.243e-05 N m

Standalone reference final angular speed is approximately 0.0100418 rad/s, so the current Basilisk direct-torque detumble behavior is close but not yet fully matched.

Known limitations

• Native Basilisk MtbEffector integration is not yet resolved. The current working baseline applies tau_B = m_B x B_B through direct body torque.
• Pointing control is scaffold only.
• WMM epoch, frame conventions, controller timing, disturbance models, and actuator details still need alignment before claiming full standalone equivalence.
• Large generated CSV output is intentionally excluded from this PR.

Development workflow

Normal development should not require rebuilding Basilisk.

Expected workflow:

1. Edit Python/Basilisk scenario code or the small ADCS core.
2. Rebuild only cpp_adcs_core/ if C++ controller code changes.
3. Run the Basilisk scenario.
4. Generate plots.
5. Compare against the standalone reference metrics.

[jtran34-ctrl]

Final local validation completed.

Validated:

• Standalone C++ reference rebuilds on Windows/MSVC.
• Basilisk detumble scenario runs.
• Detumble comparison validation passes.
• Euler/nav_euler plot is generated.
• Direct-torque pointing proof-of-concept runs.
• Pointing validation passes.
• Working tree is clean.

Known follow-ups:

• Magnetorquer-limited pointing is not solved yet.
• Native Basilisk MtbEffector wiring still needs isolated debugging.