AlgebraicFramework: Jordan/JB/JBW hierarchy, Stinespring dilation, trace-class infrastructure

[TomOleDiem]

Summary

Extends AlgebraicFramework with the Jordan-algebraic order-unit hierarchy (Jordan/JB/JBW), and
closes several gaps identified against external Lean libraries (adambornemann-glitch/Spectra,
Cobord/JordanAlgebra, and a sibling unbounded-alpha-public branch), while keeping the abstract
Jordan/JB/JBW layers independent of any concrete C*-algebra/Hilbert-space realization.

What's in this PR

• JordanOrderUnit/: quadratic representation, Jordan triple product, inner derivations and
  the structure-algebra toolkit (D_{a,b}, V_{a,b}), proving the fundamental formula for
  quadratic representations U(U a b) = U a * U b * U a (quadRep_fundamental) via the
  triple-operator commutator identity. JB/ and JBW/ layers (generated-by-one continuous
  functional calculus, square-root uniqueness, spectrum, projection resolutions), Power/,
  Quadratic/, and an Examples/SpinFactor instance.
• Algebra/: Alternative, NuclearInvolution, Derivation, Statistics — bare algebraic
  notions factored out independent of Jordan order, norms, or dynamics.
• Dynamics/: OneParameterGroup, Generator, and the bridge theorem that a one-parameter
  automorphism group's generator is a derivation.
• CStarAlgebra/: Jordan, JordanCFC, JordanCompatibility, JordanPositivity,
  JordanSpecial, JordanStatistics — the concrete realization discharging the abstract Jordan
  capabilities.
• CStarAlgebra/Stinespring/: Stinespring's dilation theorem for completely positive maps
  into B(H) — the general framework Naimark's theorem is a special case of.
• HilbertSpace/TraceClass/: Hilbert–Schmidt operators, polar decomposition, and the general
  product/ideal-norm theory needed for a genuine trace-class Banach space — closing a prerequisite
  gap that was entirely absent from Mathlib.
• HilbertSpace/Unbounded/EssentialSpectrum/: essential spectrum and Weyl's theorem on its
  invariance under relatively compact perturbation.
• OrderUnit/, Measurement/, StarAlgebra/, Representation/: assorted extensions
  (monotone completeness, weight/state equivalence and separation, bounded scalarization,
  probability law, discrete Naimark dilation) supporting the above.

EXTERNAL_INTEGRATION_PLAN.md records the full investigation of the three external sources: what
was ported, what was independently reproduced and kept instead, and what remains open (Tomita–
Takesaki modular theory; a remaining trace-class density theorem needed for
WStarAlgebra(B(H))'s predual).

Verification

• lake build PhyslibAlpha: clean, 9028 jobs, 0 errors.
• lake exe sorry_lint: passes.
• git ls-files 'PhyslibAlpha/*.lean' | xargs ./scripts/lint-style.py: 0 errors.
• rg '\b(sorry|admit)\b': no matches in any new/changed executable Lean code (only prose mentions
  in comments/roadmap docs, e.g. "0 sorry", "not even as a sorry'd restatement").
• No abstract JordanOrderUnit file imports CStarAlgebra/HilbertSpace (verified by grep),
  preserving the architectural rule that the abstract layers never depend on a concrete
  realization.

Scope notes

• A few files that came out of the same development pass are excluded because they are not
  yet sorry-free or not yet buildable, per house convention (unwired from PhyslibAlpha.lean
  until they are): WStarAlgebra/HilbertSpaceInstance.lean (3 remaining sorries, gated on a
  rankOneSpan_dense density theorem), and a small quantum-mechanics QuadraticSystem/Stone–von
  Neumann tree that is out of scope for this PR (kept locally, not included here).
• OrderUnit/State/WeightBridge.lean is renamed to WeightEquivalence.lean (extended, not
  deleted) — see the diff.

🤖 Generated with Claude Code

[github-actions]

Thank you for this pull-request (PR). If this is your first PR, welcome to the community!

Below is what will happen next. Please read carefully if you are not familiar with the process. You may open other PRs while this one is being reviewed, and can stack PRs on top of each other, so don't let these steps slow you down.

1. Some automated checks will be run on your PR. You can see the results of these checks at the buttom of your PR page. If any of these checks fail, you will need to fix the issues before your PR can be merged. You can learn more about these here, including how to run them locally, which is sometimes quicker than relying on the GitHub Actions. If you have never had a PR merged before, you may have to wait for a reviewer to manually start these checks (this is for security).

2. A reviewer will look at your PR and may ask you to make changes. This may happen a couple of days after you submit your PR, so you may need to be patient. But it should not be longer than that - if it is please bring it to the attention of the community on the Zulip. The level of review will depend on where your PR is submitted. If it is submitted to ./Physlib or ./QuantumInfo, the review will be more thorough than if it is submitted to ./PhyslibAlpha. You can find out more about what the review process is looking for in our review guidelines. If a reviewer adds an awaiting-author label to your PR, address the review comments, then please remove that label by adding a comment with -awaiting-author. This helps us keep track of reviews.

3. The reviewer will either approve your PR, or request more changes (in which case we return to step 2). Once your PR is approved, it will be merged by a maintainer, this should happen shortly after approval, though you may get more comments at this stage.

Tip: The easiest way to get have a fast review is to submit a PR that is small and self-contained, and has clear documentation explaining why things are the way they are in your chages.

If you have any problems or questions, please reach out to the community on the Zulip.

[TomOleDiem]

Wrong target repo — opening against leanprover-community/physlib instead.