Fix recursive mapperify() calls in add_edge()

[ishikaghosh2201]

Description

MapperGraph.add_edge calls self.mapperify() unconditionally on every edge added. mapperify() scans every integer level between the graph's min and max function value and calls self.subdivide_edge(...) for every edge crossing a level. subdivide_edge (on the parent ReebGraph class) internally reconnects the new vertex via self.add_edge(u, w) / self.add_edge(w, v) — and since self is a MapperGraph instance, these calls dispatch back through the overridden MapperGraph.add_edge, re-triggering a full mapperify() rescan of the entire graph for every single subdivision vertex inserted. Each nested call can itself trigger more subdivisions, each of which recurses again.

This PR:

• Adds a private helper, _subdivide_edge_no_mapperify, that reconnects the subdivision vertex using ReebGraph.add_edge directly (bypassing the MapperGraph override), and has mapperify() call it instead of self.subdivide_edge.
• No changes to add_edge's signature or default behavior, and no changes to ReebGraph.subdivide_edge itself — it's still available for direct external use.
  No public API changes anywhere.

Motivation and Context

Fixes #113 . A single edge spanning 5 integer levels triggered 11 total mapperify() calls instead of 1, and timing on a 40-node graph with distinct integer heights went 6 edges → ~9s, 8 edges → ~23s, 10 edges → ~40s — far worse than linear or quadratic growth. On real point-cloud data with denser clustering this makes computeMapper (which builds its output graph edge-by-edge the same way, via computemapper.py's __addedges) impractically slow or effectively hung.

How has this been tested?

• Verified structural equivalence directly against the unpatched package, not just node/edge counts: compared the full node count, edge count, the complete multiset of (f(u), f(v)) edge pairs, and the f-value multiset between the original and patched builds on the same input.
• Confirmed the recursion is actually gone via a call counter: a single add_edge() spanning 5 levels now triggers exactly 1 mapperify() call (was 11).
• Added regression tests to tests/test_mapper_class.py:
  --test_mapperify_called_once_per_add_edge: asserts a single add_edge() call -triggers exactly one top-level mapperify() scan.
  --test_mapperify_no_recursion_correctness: asserts the mapper invariant still holds — a single edge spanning 6 levels produces the correct subdivision vertices at every crossed integer level.
  --test_mapperify_no_exponential_blowup: asserts adding an edge spanning 18 levels completes in well under 1s, guarding against the recursion regressing.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist

• I have incremented the version number in the pyproject.toml file if a new version needs to be pushed to pypi. Note that if the number isn't incremented, the package will not be pushed to pypi, which is useful if this PR is only for updating documentation.
• My code follows the code style of this project and I have run make format to clean up the code with black.
• My change requires a change to the documentation. I have updated the documentation as necessary and compiled locally to ensure it is clean.
• I have added tests to cover my changes, and all new and existing tests passed (run make tests).

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.