Fix stale QuadItem removal after ClusterItem position updates

[Aparnamohan1312]

Summary
Fixes an issue where updateItem() may fail to remove the previously indexed QuadItem when a mutable ClusterItem changes position before being updated.

Reproduction
The issue occurs when the same mutable ClusterItem instance is reused:

1. Add a ClusterItem to NonHierarchicalDistanceBasedAlgorithm.
2. Update the item's position.
3. Call updateItem(item).
   Because the item's position has already changed, removeItem() reconstructs a new QuadItem using the updated coordinates instead of the coordinates used during insertion.

PointQuadTree.remove() then traverses the tree using the updated location, while the original QuadItem is still indexed under its previous location.

Root Cause
QuadItem caches the projected point at construction time.
removeItem() currently creates a new QuadItem from the current state of the ClusterItem. If the position has changed, the reconstructed QuadItem no longer represents the object that was originally inserted into the PointQuadTree, causing removal to search the wrong branch.

Fix
Store the original QuadItem created during addItem() in an internal lookup map keyed by the corresponding ClusterItem.
removeItem() and removeItems() now retrieve and remove the original QuadItem instance rather than constructing a new wrapper. This ensures removal uses the same cached coordinates that were used during insertion while preserving the existing public API and behavior.

Validation

• Existing add, remove, update, and bulk operations continue to behave as before.
• Added coverage for mutable ClusterItem position updates to exercise the affected update path.
• The change is internal, constant-time (O(1) lookup), and does not affect the library's public API.

---

Before submitting your PR, there are a few things you can do to make sure it goes smoothly:

• Make sure to open a GitHub issue as a bug/feature request before writing your code! That way we can discuss the change, evaluate designs, and agree on the general idea
• Edit the title of this pull request with a semantic commit prefix (e.g. "fix: "), which is necessary for automated release workflows to decide whether to generate a new release and what type it should be.
• Will this cause breaking changes to existing Java or Kotlin integrations? If so, ensure the commit has a BREAKING CHANGE footer so when this change is integrated a major version update is triggered. See: https://www.conventionalcommits.org/en/v1.0.0/
• Ensure the tests and linter pass
• Code coverage does not decrease (if any source code was changed)
• Appropriate docs were updated (if necessary)

Fixes #< #1729> 🦕