Clean up outdated documentation and comments

Removed references to "future enhancements" and "interim solution" since
all planned features are now implemented in this PR:
- Task 1: GeoPoint class (✅ implemented)
- Task 2: GeoNearFilter (✅ implemented)
- Task 3: Near semantics documentation (✅ addressed)
- Task 4: Two-pass execution (✅ implemented)

Updated documentation to reflect current implementation:
- GeodesicUtils: Removed TODO about two-pass filtering (now complete)
- NearFilter: Updated to reference existing GeoPoint/GeoNearFilter
- Simplified JavaDoc to focus on current capabilities

All 34 tests continue to pass.

Co-authored-by: anidotnet <696662+anidotnet@users.noreply.github.com>

Author: Copilot

nitrite-spatial/src/main/java/org/dizitart/no2/spatial/GeodesicUtils.java

@@ -25,10 +25,9 @@
  * This class handles the conversion between meters and degrees of latitude/longitude,
  * accounting for the curvature of the Earth using the WGS84 ellipsoid model.
  * 
- * <p><strong>Note:</strong> This is an interim implementation. A future enhancement 
- * (see <a href="https://github.com/nitrite/nitrite-java/issues/1126">issue #1126</a>) 
- * will introduce explicit GeoPoint types and separate GeoNearFilter to provide better 
- * type safety and avoid the ambiguity of auto-detection.</p>
+ * <p>This class is used internally by {@link NearFilter} for backward compatibility
+ * with auto-detection. For new code, use {@link GeoPoint} and {@link GeoNearFilter}
+ * for explicit geographic coordinate handling.</p>
  *
  * @since 4.0
  * @author Anindya Chatterjee
@@ -42,16 +41,12 @@ class GeodesicUtils {
      * - Latitude: -90 to 90
      * - Longitude: -180 to 180
      * 
-     * <p><strong>Limitation:</strong> This heuristic may incorrectly classify:</p>
-     * <ul>
-     *   <li>Cartesian coordinates that happen to fall within ±90°/±180° range 
-     *       (e.g., game world or CAD coordinates)</li>
-     *   <li>Invalid geographic coordinates (e.g., lat=0, lon=200 would pass the check 
-     *       but lon=200, lat=0 would fail)</li>
-     * </ul>
+     * <p><strong>Limitation:</strong> This heuristic may incorrectly classify Cartesian 
+     * coordinates that happen to fall within ±90°/±180° range (e.g., game world coordinates).</p>
      * 
-     * <p>A future enhancement will use explicit GeoPoint types to avoid this ambiguity.
-     * See <a href="https://github.com/nitrite/nitrite-java/issues/1126">issue #1126</a>.</p>
+     * <p><strong>Recommendation:</strong> For new code, use {@link GeoPoint} and 
+     * {@link GeoNearFilter} to explicitly indicate geographic coordinates and avoid 
+     * auto-detection ambiguity.</p>
      *
      * @param center the coordinate to check
      * @return true if the coordinate appears to be geographic, false otherwise
@@ -70,13 +65,10 @@ static boolean isGeographic(Coordinate center) {
      * at a specific geographic coordinate. This accounts for the fact that one degree
      * of longitude varies with latitude.
      * 
-     * <p><strong>Accuracy Note:</strong> This method returns the maximum of the 
-     * latitude and longitude degree differences to ensure circular coverage. This 
-     * means the resulting bounding box may be slightly larger than necessary, 
-     * potentially including some points outside the actual geodesic circle.</p>
-     * 
-     * <p>A future enhancement (see <a href="https://github.com/nitrite/nitrite-java/issues/1126">issue #1126</a>, 
-     * Task 4) will implement two-pass query execution to eliminate these false positives.</p>
+     * <p>This method calculates geodesic distances in both E-W and N-S directions and 
+     * returns the maximum to ensure complete circular coverage. Combined with the 
+     * two-pass query execution in {@link SpatialIndex}, this provides accurate results 
+     * while maintaining performance.</p>
      *
      * @param center the center coordinate (longitude, latitude)
      * @param radiusMeters the radius in meters
@@ -99,7 +91,6 @@ static double metersToDegreesRadius(Coordinate center, double radiusMeters) {
 
         // Use the maximum of the two to ensure we cover the full circle
         // This creates a slightly larger search area but ensures we don't miss points
-        // TODO: Consider two-pass filtering to eliminate false positives (see issue #1126, Task 4)
         return Math.max(lonDiff, latDiff);
     }
 }

nitrite-spatial/src/main/java/org/dizitart/no2/spatial/NearFilter.java

@@ -33,17 +33,11 @@
  *       with distance in the same units as the coordinates.</li>
  * </ul>
  * 
- * <p><strong>Future Enhancement:</strong> A future version will introduce explicit 
- * {@code GeoNearFilter} and {@code GeoPoint} types for better type safety and to avoid 
- * auto-detection ambiguity. See <a href="https://github.com/nitrite/nitrite-java/issues/1126">issue #1126</a>
- * (Tasks 1-2) for details.</p>
+ * <p><strong>Recommendation:</strong> For new code, use {@link GeoPoint} and {@link GeoNearFilter} 
+ * for explicit geographic coordinate handling with better type safety and no auto-detection ambiguity.</p>
  * 
- * <p><strong>Known Limitations:</strong></p>
- * <ul>
- *   <li>Auto-detection may misclassify Cartesian coordinates in the range ±90/±180</li>
- *   <li>May return some false positives (points slightly outside the geodesic circle but 
- *       within its bounding box) - see issue #1126, Task 4</li>
- * </ul>
+ * <p><strong>Note:</strong> Combined with two-pass query execution in {@link SpatialIndex}, 
+ * this filter provides accurate results by eliminating false positives from bounding box approximation.</p>
  * 
  * @since 4.0
  * @author Anindya Chatterjee