Add TEBD (Time-Evolving Block Decimation) for FiniteMPS [WIP]

[VinceNeede]

Summary

Adds a first TEBD algorithm for FiniteMPS, building on the new ClusterTerm/cluster_hamiltonians decomposition:

• ClusterTerm + cluster_hamiltonians: decompose a FiniteMPOHamiltonian into local terms of
  arbitrary (not just nearest-neighbor) but finite range, by tracing the Jordan-block automaton of
  each site tensor.
• TEBD: partitions those terms into Suzuki-Trotter layers of mutually non-overlapping sites
  (generalizing the even/odd bond split to arbitrary-range interactions), exponentiates each into a
  gate, and applies them via a 1st- or 2nd-order (Strang) splitting.
• Gate application (_apply_gate!) fuses each gate's FiniteMPO onto the local MPS tensors and
  losslessly assembles the whole gate result across its site range before truncating in a separate
  sweep — truncating bond-by-bond during assembly would discard information before the gate has
  even reached the sites further right.
• timestep!/timestep accept H, a precomputed Vector{<:ClusterTerm}, or precomputed
  tebd_layers output directly, so repeated calls at the same dt can skip recomputing the
  decomposition/exponentiated gates. envs is accepted only for signature parity with the shared
  time_evolve/timestep! dispatch and is otherwise unused (TEBD's update is purely local); a
  dedicated time_evolve overload that drops envs entirely will probably follow.

Why TEBD

Despite being largely superseded by TDVP-style methods for serious production use, TEBD is still
worth having: it's simple, works well for Hamiltonians with only a few, short-range terms, and is
one of the best tools for learning/teaching how MPS time evolution actually works.

Test plan

• cluster_hamiltonians tested against dense reconstruction for on-site, NN, NNN, and mixed
  Hamiltonians (test/operators/clusterterms.jl)
• Finite TEBD energy-conservation/phase test alongside the existing TDVP/TDVP2 tests
  (test/algorithms/timestep.jl)
• More thorough tebd_layers/_partition_layers coverage on a more complex (mixed-range)
  Hamiltonian — planned as a follow-up

This is still a draft — marking as such since gate application has gone through several rounds of
correctness fixes and could use more scrutiny before merging.

[codecov]

Codecov Report

❌ Patch coverage is 94.23077% with 6 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
src/algorithms/timestep/tebd.jl	96.00%	3 Missing ⚠️
src/operators/clusterterms.jl	89.65%	3 Missing ⚠️

Files with missing lines	Coverage Δ
src/MPSKit.jl	100.00% <ø> (ø)
src/algorithms/timestep/tebd.jl	96.00% <96.00%> (ø)
src/operators/clusterterms.jl	89.65% <89.65%> (ø)

... and 68 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[lkdvos]

Already going over a round of review here, but will probably try and merge #470 first in any case.

Note also that I think the work here is definitely already great, I would just like to take some time to discuss some of the overarching design principles, since there is definitely some maintenance burden here so it would be nice to get this sorted out before having too much code.

---

There are a couple questions that come to mind for me here.
One of the main reasons I have never really taken the time to implement a dedicated TEBD algorithm is that in some sense, this isn't really a full algorithm, and it is more just the combination of trotterization + gate application code.
As a result, many things feel slightly out of place to me.

For example, using timestep! with something that is really just a circuit seems a bit off, and I would argue that repeated approximate might be more appropriate.
This has the additional benefit that we still allow flexibility in what kind of fitting procedure is used, which is especially important if we allow for arbitrary-range gates.

Another thing is that the trotterization strategy has some interesting interaction with the gauging strategy. Take a nearest-neighbor trotterization for example, while it might seem beneficial to do a brick-work layered circuit on the even/odd split, there are actually also arguments to just do a staircase. Even though this leads to a circuit that is way deeper, this causes the gauge center to have to move less, therefore saving substantially on the number of QRs.

A little bit in the same direction, it can be reasonable to want to do TEBD in the Vidal gauge instead, and avoid regauging every application. This is especially true if the gates are coming from time evolution with small values of dt, as they are then close to the identity and the entire procedure "self-gauges" (see e.g. the belief-propagation papers on this).

---

This all being said, I do think that a lot of the primitives you have added here are genuinely useful to have in MPSKit.
In particular, everything surrounding gate application would be incredibly valuable to have more first-class support for.

Similarly, it could also be nice to add trotterization schemes, with a variety of options. On top of that, presumably there is some room for circuit-utilities as well.

On a separate note, I somehow always hoped that applying a gate on a subset of sites could be implemented by the combination of WindowMPS and full application, and it could be cool to try and design some of the implementations around that.