Thread persistent salsa DB through Project compilation for incremental patch validation

[bpowers]

Problem

Project::from_with_model_cb (in project.rs) creates a fresh SimlinDb::default() on every call, which drops all query caches before compilation starts. The validation/compilation path in apply_project_patch_internal (in patch.rs) calls engine::Project::from(staged_datamodel), which goes through this code path and creates a throwaway DB each time.

This means editing a single equation forces a full reparse/recompile of all unchanged variables during patch validation, rather than reusing prior salsa results. The incremental sync infrastructure (sync_from_datamodel_incremental, PersistentSyncState, salsa setters) was implemented for the commit path in libsimlin, but the validation/compilation path does not use it.

Why It Matters

• Latency for large models: every patch validation pays the cost of a full compilation, even when only one variable changed
• Wasted work: the salsa DB and its incremental sync machinery exist specifically to avoid this, but the compilation entry point bypasses them
• Developer experience: users editing large models in the interactive editor will experience unnecessary delay on each keystroke/edit

Components Affected

• src/simlin-engine/src/project.rs (Project::from_with_model_cb, Project::base_from)
• src/libsimlin/src/patch.rs (apply_project_patch_internal)
• src/simlin-engine/src/db.rs (SimlinDb)

Suggested Approach

1. Add a db_state: Option<&mut SimlinDb> (or similar) parameter to Project::base_from so callers can pass in a persistent DB
2. In apply_project_patch_internal, thread the persistent SimlinProject::db through rather than creating engine::Project::from(staged_datamodel) which discards the DB
3. Use sync_from_datamodel_incremental within the compilation path to update the existing DB
4. For failed-patch safety (the "snapshot approach" from the design plan), either:
   • Clone the DB before mutation and restore on validation failure, or
   • Sync the DB back to the previous state on failure

Relationship to #290

Issue #290 tracks a related but distinct problem: sync_from_datamodel creating fresh salsa input identities instead of updating existing ones. That issue is about how inputs are synced into a DB. This issue is about the compilation path not threading a persistent DB through at all -- there is no DB to reuse in the first place. Both need to be resolved for true incremental compilation during patch validation.

Context

Identified during code review of PR #289 (incremental compilation implementation). The current design was a deliberate choice for failed-patch safety, deferred as a follow-up optimization. The incremental sync infrastructure (PersistentSyncState, salsa setters) is already in place.