feat(workspace): add local profile persistence

[decode2]

Linked issue

Closes #50

• The linked issue has the status:approved label.

Pull request type

Select exactly one option and apply the matching type:* label.

• Bug fix (type:bug)
• New feature (type:feature)
• Documentation (type:docs)
• Refactor (type:refactor)
• Maintenance or tooling (type:chore)
• Breaking change (type:breaking-change)

Summary

• Adds validated local workspace/profile/session persistence to splice-core, with database-wide session ownership and no UI changes.
• Preserves the last known-good store through atomic replacement, backup recovery, invalid-data quarantine, and a process-safe full-transaction lock.
• Delivers SDD task 4.1 as PR 10 of 16 from approved review review-324152ec577a72ab, candidate c9f6cb71f847a8f40db543e2c74b0b3fdb742c59.

Changes

Area or file	Change
crates/splice-core/src/workspace.rs	Defines workspace profiles and schema-v1 durable JSON storage with validation, recovery, quarantine, rotation, and locking.
crates/splice-core/tests/workspace_store.rs	Covers validation, isolation, unavailable directories, corruption recovery, repeated replacement, and concurrent saves.
crates/splice-core/src/lib.rs	Exposes the workspace persistence module.
crates/splice-core/Cargo.toml, Cargo.lock	Adds serialization, temporary-directory test support, and portable file locking dependencies.

Test plan

• Ran the focused automated checks: cargo test -p splice-core --test workspace_store (9 passed), plus 20 repeated concurrent-save runs (all passed).
• Exercised the affected persistence workflow: invalid primary quarantine, default/backup recovery, repeated save rotation, offline-directory load, and competing-store serialization all passed.
• Verified relevant Windows, Linux, or WSL behavior: full Linux splice-core tests passed; Clippy passed with -D warnings; rustfmt and whitespace checks passed; cargo check -p splice-core --target x86_64-pc-windows-gnu passed.

Chained pull request context

• Previous PR: test(platform): add WSL runtime receipts #49 (PR 9/16, WSL runtime receipts)
• Next PR: PR 11/16, task 4.2 workspace command/API integration; not started in this PR.
• Review this PR first: workspace.rs persistence invariants, then the matching workspace_store.rs integrity and concurrency regressions.
• Intentionally out of scope: task 4.2 command integration, Tauri wiring, frontend state, and all UI.

Chain overview

master
 └── #49 PR 9/16: WSL runtime receipts
      └── 📍 PR 10/16: local workspace profile persistence
           └── PR 11/16: task 4.2 command/API integration (planned)
                └── ... PR 16/16

Review budget and size exception

• Review size: 583 additions + deletions across exactly five paths.
• Maintainer-approved size:exception: database-wide session uniqueness, invalid-data quarantine/default/backup recovery, portable repeated-save rotation, and deterministic concurrent-save coverage are one inseparable data-integrity boundary. Splitting them would permit an unsafe persistence implementation to land without the tests that prove its rollback and corruption behavior.
• Start: origin/master at 8f8bdf8467e8da6241ef08d72f2a0743e6ddb30e.
• End: backend-only local profile persistence with no Tauri commands or UI.

Concurrency and rollback

• Concurrency: an fs2 lock outside database rotation serializes the complete read-modify-write transaction; 20 deterministic repetitions passed.
• Rollback boundary: revert commit e2e60fb to remove only the workspace module, its tests/export, and its serde_json, tempfile, and fs2 dependency entries; no unrelated behavior is coupled to this unit.

Informational warnings

• Temporary files may remain after an interrupted/failed write and are not proactively cleaned.
• The parent directory is not explicitly synced after rename, so crash-level durability depends on filesystem behavior.
• Persisted string fields accept leading/trailing whitespace; this is inferential and does not violate the current schema contract.

These are non-blocking review INFO findings. There are no critical findings or unresolved blockers.

Contributor checklist

• I searched for duplicate issues and pull requests before starting.
• I linked an approved issue using Closes, Fixes, or Resolves.
• I selected exactly one pull request type and applied exactly one matching type:* label.
• I completed every relevant template field and included reproducible test evidence.
• I updated documentation when behavior or compatibility changed. No user-facing behavior or compatibility surface changes in this backend-only unit.
• My commits follow Conventional Commits.
• My commits contain no AI attribution, including Co-Authored-By trailers.