Rename Latexise to Latexize, so the library has one spelling

[Rafael-SOWNet]

Closes #840, taking option 1 from that issue.

Why

Stringize and Latexise do the same kind of thing, are declared next to each other, and are overridden per node in the same files. One is American, one is British. Measured on 9ae9a845:

	override string …	identifier occurrences
Stringize	65	276
Latexise	61	189

Everything else public is -ize — Stringize, Entity.Factorize, Integer.Factorize, Serialize, Deserialize. Latexise and ILatexiseable were the only members a caller had to remember the other spelling for.

What changed

Every surface the name reaches, not only the C# method:

	was	is
method	Latexise()	Latexize()
interface	ILatexiseable	ILatexizeable
string extension	"x + 1".Latexise()	"x + 1".Latexize()
helper	MathS.Latex(ILatexiseable)	MathS.Latex(ILatexizeable)
native entry point	entity_latexise	entity_latexize
C++ wrapper	Entity::Latexise()	Entity::Latexize()
F#	latexise	latexize

No forwarding member. #832 has just finished deleting 28 members that accumulated as forwarders; adding a permanent one here would undo that on the same day.

MathS.Quantum.Factorise deliberately keeps its spelling — renaming it to Factorize would give the library two unrelated public Factorize methods (expression factoring on Entity, tensor factorisation on a quantum state), which is worse than the inconsistency. It wants a distinguishing name, which is not decided here.

One file deliberately not renamed

Sources/Samples/SampleNet5/Program.cs keeps Latexise. It compiles against PackageReference AngouriMath 1.3.0, not against this source, so the old name is the correct one there until the sample is repointed at 2.0. Renaming it broke the build, which is how this was found.

Also fixed

BREAKING-CHANGES.md claimed "nothing parses LaTeX". CSharpMath does — that is what #822 established and what AGENTS.md already says. Corrected rather than left standing in the release notes.

Measured

Every project that builds on Linux, built individually:

project	result
AngouriMath	0 errors
UnitTests	0 errors
AngouriMath.FSharp	0 errors
AngouriMath.Interactive	0 errors
AngouriMath.CPP.Exporting	0 errors
AngouriMath.Terminal.Lib	0 errors
SampleNet5	0 errors

Passed! - Failed: 0, Passed: 6049, Skipped: 14, Total: 6063 - UnitTests.dll (net10.0)

Downstream, and the order it has to happen in

CSharpMath.Evaluation is affected in four files — and more deeply than a call-site count suggests: its MathItem record implements ILatexiseable and overrides Latexise().

It cannot be fixed first, or in parallel. It consumes <PackageReference Include="AngouriMath" Version="1.4.0" />, so a rename there does not compile until 2.0 is on NuGet. The order is forced:

1. this PR,
2. publish 2.0 to NuGet,
3. one PR to CSharpMath that bumps the package reference to 2.0 and renames — atomically, since neither half compiles without the other.

🤖 Generated with Claude Code

[Rafael-SOWNet]

Reviewed the rename itself as mechanical work — it is complete and consistent.

• 68 public members renamed 1:1, no strays: PublicApi.txt shows exactly 68 removed and 68 added, including interface ILatexiseable → ILatexizeable.
• The only Latexise left under Sources/ is Samples/SampleNet5/Program.cs, and that is right — it compiles against the published 1.4.0 package rather than the local project, so renaming there would break the build in a way that reads like a missed call site.
• BREAKING-CHANGES.md carries the entry, with the native entry point and the F# function listed alongside the C# members.

Worth noting that PublicApi.txt (#841, merged an hour before this) caught the whole thing on the very next PR, which is the intended behaviour: a 68-member break is now a reviewable diff rather than something a consumer discovers at compile time.

One thing to decide before merging: there is no shim

Latexise is removed outright — no [Obsolete] forwarder. That is defensible for a major, and it is documented, so this is not an objection. But the consequence is worth naming, because the interface rename is the sharper edge and it is not symmetrical with the method rename.

Measured against verybadcat/CSharpMath, a named downstream consumer:

where	use	breaks?
CSharpMath.Evaluation/Interpret.cs	ILatexiseable as a parameter type	yes
CSharpMath.Evaluation/Interpret.cs	latex.Latexise()	yes
CSharpMath.Evaluation.Tests/EvaluationTests.cs	entity.Latexise()	yes
CSharpMath.Evaluation/Evaluation.cs	MathItem.Latexise()	no — their own member

(Correcting my own earlier count on #821: I said five call sites. Three of them are AngouriMath's API; the rest are CSharpMath's own abstract method, which is unaffected.)

The asymmetry: a method rename can be softened by keeping an [Obsolete] forwarder. An interface rename cannot, not cleanly. Keeping an empty [Obsolete] interface ILatexiseable : ILatexizeable would let a consumer's parameter type still compile, but only if Entity implements both — otherwise passing an Entity where ILatexiseable is expected still fails. So the shim that looks obvious does not actually work without Entity carrying two interfaces, which is worse than the break.

So my recommendation is to ship it hard, as written here — the half-measure costs more than it buys, 2.0 is the release for exactly this, and the document is honest about it. What I would add is not code but a heads-up to CSharpMath, since the fix on their side is three lines and they cannot act on a change they have not seen.

The one thing I would not do is add the shim for the method only. That leaves Latexise() working while ILatexiseable has vanished, so a consumer gets a partial migration that compiles until it does not — worse than a clean break in both.