Develop NonlinearSolve sublibraries in downstream CI

[ChrisRackauckas-Claude]

Ignore this PR until it has been reviewed by @ChrisRackauckas.

Summary

• make every downstream matrix row declare the caller project paths developed into the target
• develop NonlinearSolveBase, SciMLJacobianOperators, and NonlinearSolveFirstOrder for the BoundaryValueDiffEq target
• keep the existing root-package behavior for the other downstream targets

BoundaryValueDiffEq exercises these NonlinearSolve sublibraries rather than the monorepo root package. Developing only the root project could therefore leave that job green while testing registry releases instead of this checkout.

This depends on SciML/.github#115 and on publishing that merged reusable workflow at the moving v1 tag before this caller job can start.

Local verification

• actionlint .github/workflows/Downstream.yml
• julia +1.12 --startup-file=no -m Runic --check .
• git diff --check
• exact local replay against BoundaryValueDiffEq with GROUP=All: all three selected local projects resolved and precompiled as path dependencies

The exact downstream test suite itself did not run because of a legitimate current dependency incompatibility: NonlinearSolveFirstOrder requires LinearSolve 5 while BoundaryValueDiffEq's test project restricts LinearSolve to 3.12–3. I did not alter compatibility or suppress the resolver failure; this PR is limited to correcting which source projects the downstream job develops.

[ChrisRackauckas-Claude]

The previous IntegrationTest run (29416743555) was rejected with startup_failure before the shared SciML/.github@v1 workflow release. I rebased the workflow-only commit onto current master (new head 01d2f7d) and pushed with a checked --force-with-lease; this both incorporates the two intervening upstream commits and retriggers the released reusable workflow.

⎿ Setting 3-hour timer for CI completion as per CLAUDE.md instructions...
Current time: 2026-07-16 13:09:46 EDT
Will check CI results at: 2026-07-16 16:09:46 EDT

[ChrisRackauckas-Claude]

Post-release CI audit note for job 87689840720:

• The released shared workflow accepted this PR's new input and selected all three intended local projects:
  • lib/NonlinearSolveBase
  • lib/SciMLJacobianOperators
  • lib/NonlinearSolveFirstOrder
• It selected BoundaryValueDiffEq's root project with GROUP=All.
• The target test environment then hit the expected LinearSolve incompatibility (BoundaryValueDiffEq test compat 3.x versus developed NonlinearSolveFirstOrder requiring 5).
• The current released SciML/.github@v1 catch converted that ResolverError into a green job before any BoundaryValueDiffEq test group ran.

I reproduced the same environment locally on Julia 1.12.6 with the catch removed; Pkg.test exited 1 at that resolver conflict. SciML/.github#117 removes the catch and is the infrastructure fix.

So this job proves that upstream-subdirs is wired correctly, but its green status is not a test pass and should not be read as one.

[ChrisRackauckas-Claude]

Follow-up classification of the complete IntegrationTest run 29518620844:

All seven matrix rows selected their declared group and upstream project paths, but every row then took the released workflow's resolver-success catch before producing a test summary:

• BoundaryValueDiffEq / All
• DiffEqCallbacks / Core
• ModelingToolkit / InterfaceI
• ModelingToolkit / InterfaceII
• ModelingToolkit / Initialization
• OrdinaryDiffEq / Interface
• OrdinaryDiffEq / Regression

For each job log, the catch message occurs twice (once in the echoed run script and once when executed) and Test Summary: occurs zero times. Therefore none of the seven green statuses is a real downstream test pass.

SciML/.github#117 is the focused fix: it removes this catch so each incompatibility becomes a visible red job. This PR still correctly fixes which local subprojects are developed; the current green integration run should only be used as wiring evidence, not test-execution evidence.