Related Issue

Fixes #1793

Description

Deleting a Project currently removes its task/history state from the UI but can leave the durable Project row behind. Deleting a Space then fails with space_has_projects, even though the Space deletion confirmation says the Space and all of its Projects will be permanently deleted.

This change makes the destructive actions match that UI contract.

Root cause

SpaceService.delete_space() rejects any Space that still has Project rows, including archived Projects.
deleting the final ChatHistory removes triggers but does not remove the durable Project row.
Project deletion can fan multiple history DELETE requests out in parallel, so final-history cleanup needs to serialize per Project.

Changes

add a shared deletion service for Project/Space dependent rows
remove the durable Project when its final history is deleted
serialize concurrent history deletion on the Project row
make Space deletion cascade through contained Projects
add DELETE /spaces/{space_id}/projects/{project_id} for direct Project deletion
keep ownership checks on both Project and Space deletion
add regression tests covering Project deletion, Space cascade deletion, and ownership isolation

The cleanup covers chat histories, trigger executions/triggers, Project/Space memory, pending file overlays, and Space file-index rows before removing the parent records.

Testing

Regression tests are included in server/tests/test_space_project_deletion.py for:

deleting a Project while preserving its parent Space
deleting a Space together with its Projects and Space-scoped data
refusing to delete a Project owned by another user

Manual reproduction was on Windows: Project deletion appeared to succeed in the UI, but the remaining server Project row caused subsequent Space deletion to fail. This PR is currently a draft pending branch test/CI results.