trim of zero module takes longer than expected

Nobody has claimed this yet.

Sometimes trimming the zero module can take a while:
```
Macaulay2, version 1.16
with packages: ConwayPolynomials, Elimination, IntegralClosure, InverseSystems,
LLLBases, MinimalPrimes, PrimaryDecomposition, ReesAlgebra,
TangentCone, Truncations

i1 : R = ZZ/32003[a..e]

o1 = R

o1 : PolynomialRing

i2 : I = ideal(a^4-b^4,b^4-c^4,c^4-d^4,d^4-e^4,a^3*b+b^3*c+c^3*d+d^3*e+e^3*a)

4 4 4 4 4 4 4 4 3 3 3 3 3
o2 = ideal (a - b , b - c , c - d , d - e , a b + b c + c d + d e + a*e )

o2 : Ideal of R

i3 : M = comodule I

o3 = cokernel | a4-b4 b4-c4 c4-d4 d4-e4 a3b+b3c+c3d+d3e+ae3 |

1
o3 : R-module, quotient of R

i4 : elapsedTime 0*M == 0
-- 0.10836 seconds elapsed

o4 = true

i5 : elapsedTime trim(0*M)
-- 4.49107 seconds elapsed

o5 = subquotient (0, | d4-e4 c4-e4 b4-e4 a3b+b3c+c3d+d3e+ae3 a4-e4 |)

1
o5 : R-module, subquotient of R
```
Can the logic in `trim` be improved to handle cases like this?

Reproduce the reported Macaulay2 session and compare `trim(0*M)` with `0*M`; the payload names no source file or test, so locate the `trim` entry point before deciding where the delay occurs. Done means the zero-module case completes materially faster while preserving the displayed module result, with a regression test for this example.

Written by the indexing model from the issue text.