Fix update_weekly: resolve all six unsatisfiable benchmark folders + run update job on Julia 1.12

[ChrisRackauckas-Claude]

Problem

The default-branch Weekly Update workflow (update_weekly) is red on master. The job (.github/workflows/update.jl) runs Pkg.update() in every benchmarks/* folder in a single Julia process and aborts on the first unresolvable environment. It died first on BayesianInference, but a full resolution audit (Julia 1.10) showed six folders whose [compat] is unsatisfiable — so fixing BayesianInference alone would have just moved the crash to the next folder.

Root cause

Commit fb9a3b66 mechanically bumped every benchmark Project.toml to the v7 / SciMLBase-3 / RecursiveArrayTools-4 stack. Six folders depend on something that cannot live in that stack, or on a package not available on the job's Julia version:

folder	conflict
BayesianInference	Turing/DiffEqBayes pin SciMLBase ≤2; RAT 4/ODE 7 need SciMLBase 3
Bio	ReactionNetworkImporters 0.15 needs MTK 9; project pins ModelingToolkit 11
HybridJumps	PiecewiseDeterministicMarkovProcesses 0.0.10 ⊥ RecursiveArrayTools 4
Jumps	JumpProblemLibrary 1 needs Catalyst 2; project pins Catalyst 16 (+ PDMP 0.0.10 ⊥ RAT 4)
ParameterEstimation	DiffEqParamEstim 2 pins SciMLBase ≤2 (no SciMLBase-3 release exists); project pins MTK 11 / ODE 7 / RAT 4
LinearSolve	ParU_jll only has 1.0.0/1.0.1, both requiring Julia ≥1.12; the job ran on 1.10

Fix

Compat adjustments (tightest bound that restores a satisfiable resolution, keeping deps as new as possible):

• BayesianInference: OrdinaryDiffEq 7→6, RecursiveArrayTools 4→3 (back to the SciMLBase-2 generation Turing/DiffEqBayes require).
• Bio: ReactionNetworkImporters 0.15→1 (RNI 1 supports Catalyst 16 and the MTK-11 generation — keeps the SciMLBase-3 stack).
• HybridJumps: PiecewiseDeterministicMarkovProcesses 0.0.10→0.0.12 (floor bump; 0.0.12 supports RAT 4 / SciMLBase 3 / Sundials 6).
• Jumps: JumpProblemLibrary 1.0.0→2 (supports Catalyst 16); PDMP 0.0.10→0.0.12.
• ParameterEstimation: ModelingToolkit 11→9, OrdinaryDiffEq 7→6, RecursiveArrayTools 4→3 (DiffEqParamEstim has no SciMLBase-3 release; revert to the SciMLBase-2 generation matching the last-working Manifest — MTK 9.61 / ODE 6.90 / RAT 3.27 / SciMLBase 2.72).

Harness change for LinearSolve:

• .github/workflows/update.yml: bump the Weekly Update job from Julia 1.10 → 1.12. ParU_jll (used by ParUFactorization() in the LinearSolve benchmark) requires Julia ≥1.12, and LinearSolve's committed Manifest.toml already declares julia_version = "1.12.4". Dropping ParU would weaken the benchmark, so instead the update job is moved to the Julia version the stack now targets.

Local verification (resolution-only, mirroring the job's Pkg.update resolver)

• Reproduced each Unsatisfiable failure on the unmodified Project.tomls on Julia 1.10 (matches the exact resolver error in the failing CI log).
• With these fixes, all 38 benchmark folders resolve cleanly on Julia 1.12 (38/38 OK), including the six above (also confirmed individually).
• update.jl's preamble (Pkg.add(["Git","GitHub","Dates"])) resolves and installs on 1.12.

Note: only resolvability (what update_weekly exercises) was verified. The benchmark *.jmd scripts were not executed against the bumped deps — Bio/Jumps run heavy models on self-hosted runners — so the per-benchmark "Run:" PR checks should be watched on review.

Please ignore until reviewed by @ChrisRackauckas

[ChrisRackauckas-Claude]

Expanded this PR to fully green update_weekly (commit 6732675). A resolution audit of all 38 benchmarks/* folders showed the BayesianInference-only fix was insufficient — the single-process Pkg.update() loop would have crashed next on Bio, HybridJumps, Jumps, ParameterEstimation (all unsatisfiable [compat]), and on LinearSolve (ParU_jll needs Julia ≥1.12 but the job ran on 1.10).

Added minimal compat fixes for the four, and bumped .github/workflows/update.yml from Julia 1.10→1.12 for LinearSolve (its Manifest already targets 1.12.4). Verified locally: all 38 folders now resolve cleanly on Julia 1.12 (38/38). Only resolvability was checked — the heavy .jmd benchmarks were not run against the bumped deps.