Standardize orthogonal CI buckets and notebook validation

[acgetchell]

Goal

Adopt the same validation shape as delaunay: just ci should be the GitHub-equivalent flat union of leaf validators, and each changed surface should have a focused validator that can be composed once.

Deliverables

• Make just ci compose leaf validators directly instead of depending on broad nested bundles.
• Keep focused changed-surface validators for local work: docs/config/Python/notebooks/core Rust/unit tests/doctests/integration tests/benchmarks/examples.
• Keep test-unit, test-doc, and test-integration as focused recipes for local or changed-surface validation.
• Add a broad Rust CI nextest bucket, for example test-rust-ci, that runs lib unit tests and integration tests together with cargo nextest run --release --profile ci --lib --tests.
• Wire just test-rust and just ci through test-rust-ci plus the separate doctest bucket, rather than compiling unit tests in the default profile and integration tests again in release.
• Keep doctests as their own bucket because cargo test --doc is not covered by nextest.
• Keep broad clippy --all-targets as an optional sweep outside just ci if it duplicates tests/examples/benches that have their own validators.
• Document the fast-cycle guidance: run the smallest changed test/doctest/integration crate first; compose focused buckets once for final non-core changes; run full just ci for core Rust or GitHub-equivalent validation.

Desired validation buckets

• GitHub Actions: action-lint + zizmor
• Markdown: markdown lint + spell check
• TOML: parse, Taplo lint, Taplo format check
• YAML/CFF: dprint/yamllint + citation checks when applicable
• Python: Ruff format/check, ty, pytest
• Notebooks: reusable checker CLI plus fast headless execution bucket
• Core Rust: rustfmt, core/library Clippy, rustdoc, repository Semgrep if present
• Rust focused tests: unit, doctest, integration recipes for changed-surface validation
• Rust broad CI tests: one release-profile nextest bucket for lib unit + integration tests, plus separate doctests
• Benchmarks: benchmark harness compile
• Examples: example validation

Notebook standard

Even if la-stack has no notebooks today, add or plan for the standard notebook leaf so future notebooks do not invent a separate workflow:

• notebook-lint: validate .ipynb JSON, reject committed outputs/execution counts, extract code cells, run Ruff format/check and ty, compile cells.
• notebook-check: notebook-lint plus fast headless execution, writing executed notebooks/artifacts under target/notebooks without mutating source notebooks.
• notebook-check-slow: explicit slow notebook execution bucket.
• notebook-clear-outputs-all: mutating cleanup helper.

Prefer a reusable scripts/notebook_check.py CLI for lint/hygiene/extracted-code checks, with Just recipes owning headless execution policy.

CI shape

just ci should compose the leaf validators directly. Avoid broad nested bundles that precompile a target class and then run it again. In particular, avoid the debug-plus-release Rust test split in broad CI: --lib and --tests select different target classes, but running them in different profiles recompiles the library twice. For scientific correctness and less duplicate compilation, broad Rust CI should use one release-profile nextest pass for lib unit + integration tests.

[acgetchell]

Update from the delaunay CI test-wiring pass: keep focused recipes for local/changed-surface validation (test-unit, test-doc, test-integration), but broad Rust workflows should avoid the debug-plus-release profile split. Add a CI Rust nextest bucket such as test-rust-ci and wire just test-rust / just ci through cargo nextest run --release --profile ci --lib --tests, with doctests remaining in their separate just test-doc bucket. Rationale: --lib and --tests select different target classes, but running unit tests in the default test profile and integration tests in release recompiles the library in both profiles. For scientific correctness and less duplicate compilation, broad CI should use one release-profile nextest pass for lib unit + integration tests.