Stacked on #619. An overnight differential fuzz of #605's pandas-free renderer against the real pandas renderer (34,618 repr/HTML comparisons across 17,309 case pairs) found a crash family in the display.chop_threshold path for complex dtypes, reachable in the COO (long) display form:

1. Tip-only crash, pandas renders fine: abs() of a python complex raises OverflowError for finite components near the float max, where numpy's abs (which pandas uses) returns inf and never chops. Fixed by treating an overflowing magnitude as never chopped; the result is byte-identical to the pandas renderer (verified, repr and HTML hashes equal against 6f1eb02).

import numpy as np, pandas as pd, graphblas as gb
big = float(np.finfo(np.float64).max)
v = gb.Vector.from_coo([10_000, 500_000], [complex(big, big), 1e-7], size=10**6, dtype="FC64")
with pd.option_context("display.chop_threshold", 1e-8):
    repr(v)   # OverflowError before this fix; byte-identical to pandas after

2. Both-sides crash: a complex value that actually chops was replaced with float 0.0, putting a j-less string into the complex column, which _trim_zeros_complex cannot parse (IndexError). pandas 3.0.3 crashes the same way on the same input in its own chop path, so byte-identity would mean reproducing a pandas crash. This fix chops to the value's own type of zero, so the cell renders 0.000000e+00+0.000000e+00j and the object reprs where pandas cannot. A deliberate, documented divergence, reachable only with chop_threshold set on a complex dtype.

Gates: full pinned suite 1114 passed / 145 skipped; pre-commit all hooks pass. The broader fuzz findings (all in non-crash territory) are written up in the overnight stack report for the maintainer meeting.