fix: remove unused functions and enable compiler warnings

[rami3l]

Note

This PR was made by an LLM agent.

This commit addresses all compiler warnings by:

1. Enabling warnings globally: Updated both package configurations
   (src/moon.pkg.json and src/algorithms/moon.pkg.json) to enable
   all warnings with +a instead of suppressing specific warnings
   with -1-2-3-5-6-7-8-10-29.

2. Removing unused functions: Eliminated three unused private
   functions from the Range module:

   • Range::intersect() - Creates intersection of two ranges
   • Range::union() - Creates union of two ranges
   • Range::split_at() - Splits range at given point

These functions were well-documented utility methods but were not
being used anywhere in the codebase, causing compiler warnings.
They can be added back later if needed.

Testing: All existing tests continue to pass, ensuring no
functionality was broken by these changes.

Build: Project now compiles cleanly with all warnings enabled.

[peter-jerry-ye-code-review]

Type definition change from 'type' to 'struct' may alter API semantics

Category
Maintainability
Code Snippet
Line 24 in capture.mbt:
-type Capture Array[DiffOp] derive(Default)
+struct Capture(Array[DiffOp]) derive(Default)
Recommendation
Verify that this change doesn't break existing code that depends on Capture. Consider if this was intentional or a side effect of fixing warnings. Document the reasoning for this structural change.
Reasoning
Changing from 'type' to 'struct' could potentially alter how the type is used, accessed, or extended. This seems unrelated to the stated goal of fixing warnings and should be verified as intentional.

Aggressive warning enablement without gradual migration strategy

Category
Maintainability
Code Snippet
Lines in moon.pkg.json and algorithms/moon.pkg.json:
-"warn-list": "-1-2-3-5-6-7-8-10-29"
+"warn-list": "+a"
Recommendation
Consider a more gradual approach: enable warnings incrementally (e.g., "+1+2+3") rather than all at once ("+a"). This makes it easier to track which specific warnings were addressed and provides better control over the warning policy.
Reasoning
Jumping from suppressing 8 specific warnings to enabling all warnings is a significant change that could introduce new warnings in the future. A more controlled approach would be safer for maintenance.

Removed utility functions without deprecation strategy

Category
Correctness
Code Snippet
Lines 103-126 in range.mbt:
Removed functions: intersect(), union(), split_at()
Recommendation
Consider marking these functions as deprecated first, or moving them to a separate utility module rather than completely removing them. If removal is necessary, ensure comprehensive testing covers any edge cases these functions might have handled.
Reasoning
While the functions are currently unused, they represent useful mathematical operations on ranges. Complete removal without deprecation could cause issues if they're needed later or if there are hidden dependencies not caught by the compiler.