`MathS.Quantum.Factorise` collides with `Entity.Factorize` and needs a distinguishing name in 2.0

[Rafael-SOWNet]

Deliberately left out of #842, which renamed Latexise to Latexize. Filing it separately because it is the same kind of decision — a breaking rename that only 2.0 can absorb — but it has a different answer, and #842 should not have quietly made it.

The problem

Two public methods, one letter apart, doing unrelated things:

member	operation
Entity.Factorize(int level = 2) (Evaluation.Definition.cs:350)	algebraic factoring of an expression
MathS.Quantum.Factorise(Entity) (MathS.cs:6981)	tensor factorisation of a quantum state

They take and return the same shapes, so neither the type system nor autocomplete protects a caller who reaches for the wrong one. After #842, Factorise is also the last -ise spelling left in the public surface.

Why the obvious fix is wrong

Renaming Factorise to Factorize makes the spelling consistent and the API worse: the library would then have two public Factorize methods, in different classes, doing unrelated things. Consistent spelling is not the goal — a caller being able to tell them apart is.

What it should probably be

MathS.Quantum already contains the inverse operation, named clearly:

public static Entity Factorise(Entity state)     // superposition -> tensor product
public static Entity TensorExpand(Entity state)  // tensor product -> superposition

TensorExpand names the domain and the direction. Its inverse does not. Renaming Factorise to TensorFactorize gives a matched pair — TensorFactorize / TensorExpand — fixes the spelling as a side effect, and removes the collision with Entity.Factorize entirely.

The options

1. MathS.Quantum.Factorise → MathS.Quantum.TensorFactorize. Pairs with TensorExpand, ends the collision, ends the last -ise. Breaking, so 2.0 or never.
2. → Factorize. Spelling consistent, collision made worse. Not recommended.
3. Leave it. Then the collision is permanent, since after 2.0 there is no cheap moment to rename it.

Why now

Same argument as #840: this is a public member, so the rename is breaking, so 2.0 is the last release that can absorb it. Shipping 2.0 undecided chooses option 3 by default. Unlike Latexise there is no known external consumer, so the cost is lower — which is an argument for doing it, not for deferring it.

Recommendation is option 1. Happy to do it; it is a small change, and #842 has just proven the tooling catches everything a rename touches — the public-surface baseline from #841 fails until the record is regenerated.