deleteSlice misses quality_gates FK cascade and leaves orphan rows in 4 sibling tables

[jmendozaeliaseras-hub]

Summary

deleteSlice() in src/resources/extensions/gsd/gsd-db.ts (line ~2150 at 33c00aaff) manually cascades verification_evidence → tasks → slice_dependencies (both directions) → slices, but does not delete quality_gates rows — and quality_gates carries a true foreign key to slices:

-- db-base-schema.ts:275
FOREIGN KEY (milestone_id, slice_id) REFERENCES slices(milestone_id, id)

Deleting any slice that has quality_gates rows fails with FOREIGN KEY constraint failed (with FK enforcement on), or silently leaves orphan gate rows.

Four more tables reference the deleted slice by (milestone_id, slice_id) without an FK→slices — gate_runs, replan_history, assessments, artifacts — and are left as orphan rows. deleteMilestone already does equivalent orphan cleanup for its scope, so deleteSlice is inconsistent with the established pattern.

Reproduction

1. Create a milestone + slice; let a gate definition write a quality_gates row for the slice.
2. Call deleteSlice(milestoneId, sliceId).
3. Observe FOREIGN KEY constraint failed (FKs on) or orphaned quality_gates rows (FKs off).

Schema audit (why exactly these five tables)

Table	FK→slices?	Handled by deleteSlice today?
tasks	YES	yes
slice_dependencies	YES (both directions)	yes
quality_gates	YES (db-base-schema.ts:275)	no — the actual FK bug
gate_runs	no	no — orphan rows
replan_history	no (FK→milestones)	no — orphan rows
assessments	no (FK→milestones)	no — orphan rows
artifacts	no	no — orphan rows

Proposed fix

Add five manual DELETEs to the existing cascade (matching the current manual-DELETE style, no schema migration): quality_gates before tasks, then gate_runs / replan_history / assessments / artifacts orphan cleanup, then the existing flow. I have this working locally with a regression test and will submit a PR referencing this issue.

Prior art: #5698 / #5787 (both closed) touched adjacent lifecycle areas but not this FK gap.