Fix braid orientations in code involving GenericMPSTensors

[borisdevos]

A couple of braids throughout the code involving GenericMPSTensors were inconsistent for anyonic symmetries, where over-and underbraiding aren't symmetric. In particular, density matrices represented as MPS fall under this category. When it comes to braiding tensors within @plansor calls, I just had to invert the orientation ("handedness" as I called it scattered throughout the code), while for the prepared AC2 derivative I had to switch around some levels.

Summary of things I changed:

• transfer_left/transfer_right for GenericMPSTensor (the density-matrix MPO transfer): the ancilla/MPO-leg
  crossing was wrong-handed (τ → τ'). This I caught through dot(ρ_mps, O, ρ_mps) disagreeing with the dense reference tr(ρ' * O * ρ) for Fibonacci.
• contract_mpo_expval2: one of its two crossings needed inverting.
• unprepared AC for GenericMPSTensor, unprepared AC2 for (3,3)tensors, and preparedAC` (3,1) needed some reversed braidings.
• prepared AC2 (3,3) braid crossings ordering changed through levels (largely through trial and error)
• _mpo_to_mps: densify a Jordan MPO tensor before braiding its physical leg against the virtual leg. Previously space mismatched as it tried braiding a sumspace with a regular space.

What's still broken is expectation_value(ρ::FiniteMPO, H::FiniteMPOHamiltonian) for anyonic sectors with a similar spacemismatch as above. Even if a regular/sumspace braiding constructor existed (i.e. is well-defined), this space mismatch would then occur deeper, where a sumspace would need to braid with an MPS's leg. I didn't want to play around with densifying all these sumspaces. I did find a workaround, namely densifying the Jordan MPO tensor itself (not the full density matrix), which is added to the tests.

So I had to add a bunch of tests to actually catch these, where I tried to make them accessible at user level. In general we don't test anyonic symmetries as rigorously. Of course personal experience with anyonic spin chains tells me there's not too much wrong there, but it's worth looking at. Though I do believe we've made everything Hamiltonian-related planar.

Things I haven't looked at yet, a bit outside the "density matrix" scope of this PR:

• There are braids in the transfers involving excitation B tensors. Some parts explicitly check the ambiguity of the braiding, hence not supported anyonic symmetries.
• Time evolution with the WII algorithm does some braiding to get its blocks.

Checklist

• Tests pass locally (julia --project=test test/runtests.jl, or the relevant subset)
• Documentation updated, if this PR changes public API (docstrings, docs/src/)
• Runic formatter is run
• Changelog entry added under [Unreleased] in docs/src/changelog.md, if this PR is user-facing (new feature, behavior change, bug fix, deprecation, or removal)

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

Files with missing lines	Coverage Δ
src/algorithms/derivatives/mpo_derivatives.jl	78.52% <100.00%> (+49.69%)	⬆️
src/algorithms/expval.jl	91.95% <100.00%> (+43.71%)	⬆️
src/operators/mpo.jl	89.61% <100.00%> (+12.65%)	⬆️
src/transfermatrix/transfer.jl	76.66% <ø> (+13.33%)	⬆️

... and 66 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]

Do you know which convention we are then now following? I think your test of being compatible with tr(...) is great, but that basically only means that the braiding we do in convert(FiniteMPS, ::FiniteMPO) has to be consistent with the actions, bending either in front or to the back, so we could also change that function

[borisdevos]

Do you know which convention we are then now following? I think your test of being compatible with tr(...) is great, but that basically only means that the braiding we do in convert(FiniteMPS, ::FiniteMPO) has to be consistent with the actions, bending either in front or to the back, so we could also change that function

We're underbraiding the domain physical leg across the domain virtual leg of the MPO. I'm currently checking just making this an overbraid and seeing how much of the changes I made can be undone. I have a feeling this might just work everywhere except in the two-site code with multiple braids, but maybe I can just change some braid orders there.

[lkdvos]

I don't have any preference on which one we use in the end, it's mostly just a matter of documenting this properly I'd say

[borisdevos]

I'll see where I can document this cleanly. Also I need to figure out how to make these tests less expensive. It's crazy how much longer these tests take in julia 1.12 compared to 1.10