Import issquare from SciMLOperators in ForwardDiff extension

[ChrisRackauckas-Claude]

Ignore until reviewed by @ChrisRackauckas.

Summary

• import issquare directly from its public owner, SciMLOperators, in LinearSolveForwardDiffExt
• add a focused square split-dual initialization regression

Root cause

LinearSolveForwardDiffExt called bare issquare while relying on using SciMLBase to make the name available indirectly. SciMLBase commit b9c3507a (Make strict QA owner-contract clean (#1472)) stopped reexporting SciMLOperators names. With SciMLBase 3.40.1, ForwardDiff initialization of a square linear problem therefore raised:

UndefVarError: `issquare` not defined in `LinearSolveForwardDiffExt`

SciMLOperators.issquare is exported, has a docstring, and is included in SciMLOperators' rendered interface documentation. The ChainRules extension already uses the same owner import.

Investigation

• searched open and recent merged LinearSolve PRs; no existing PR fixes this failure
• reproduced the failure on unmodified LinearSolve fd8271c1 with SciMLBase 3.40.1
• ran the identical probe with registered SciMLBase 3.39.1; it passed with gradient [0.16, 0.04]
• applied only the owner import and confirmed the SciMLBase 3.40.1 probe passes with the same gradient

Verification

• exact test/Core/forwarddiff_overloads.jl on SciMLBase 3.40.1: pass
  • new focused test: 1/1
  • all remaining testsets in the file completed successfully
• exact OrdinaryDiffEq nested-AD regression on SciMLBase 3.40.1:
  • nested ForwardDiff over implicit NonlinearSolveAlg: 4/4
  • DFBDF initialization with internal ForwardDiff Jacobian: 1/1
• registered SciMLBase 3.39.1 GROUP=QA:
  • QA: 20 pass, 2 pre-existing broken
  • JET: 34 pass, 8 pre-existing broken
  • Allocation QA: 48/48
  • SupernodalLU Allocation QA: 8/8
• whole-repository Runic check: pass
• git diff --check: pass

The official Core run against SciMLBase 3.40.1 reached 629 passes, then stopped at the independent existing test use of bare cache_operator. The same cache_operator error reproduces on unmodified LinearSolve fd8271c1; it is intentionally outside this focused PR and is being investigated separately. QA against SciMLBase 3.40.1 likewise reaches independent existing owner-contract failures for stale has_concretization and a qualified LinearSolve.SciMLOperators access. The registered 3.39.1 QA control is green as reported above.

[ChrisRackauckas-Claude]

CI triage for the current run:

• The spell-check failure is independent and reproduces on clean main at fd8271c1; it was bounded to 4c58ce27 and is fixed in draft test: spell out SupernodalLU threshold variable #1124. Local typos 1.48.0, whole-repository Runic, and official GROUP=Core all pass on that branch.
• SciMLSensitivity.jl/Core1 fails during dependency resolution before tests because the current registered compatibility stack cannot select the newer SciMLBase/LinearSolve combination. The focused SciMLSensitivity floor follow-up is draft Allow SciMLBase before 3.40 is registered SciMLSensitivity.jl#1575; the exact resolver failure was reproduced locally.
• The GPU failure is an unseeded BlockDiagonal/SimpleGMRES numerical mismatch in hosted GPU CI. This machine has no GPU, so I have not claimed a local reproduction; it remains a separate clean-main investigation rather than being folded into this owner-import PR.
• The independent bare cache_operator clean-main failure named in the PR body is now fixed separately in draft Import cache_operator from SciMLOperators in Core tests #1126, with its own dependency-boundary and Core/QA evidence.

The scoped #1125 regressions remain locally green as recorded in the PR body. No test has been skipped, disabled, or loosened.