Guard genlocke-related data integrity edge cases. Audited existing endpoints for gaps in validation when runs, encounters, or legs interact with genlocke tracking.
- [x]**Block deletion of genlocke-linked runs.**`DELETE /runs/{id}` now returns 400 if the run belongs to a genlocke leg. (`runs.py`)
- [x]**Block reactivation of completed/failed genlocke-linked runs.**`PATCH /runs/{id}` now returns 400 when trying to set status back to `active` on a genlocke-linked run. (`runs.py`)
### High
- [x]**Guard encounter deletion against transfer references.**`DELETE /encounters/{id}` now checks for GenlockeTransfer references and returns 400 instead of a raw FK constraint violation. (`encounters.py`)
### Already handled (verified during audit)
- [x] Advance leg twice — guarded by "next leg already has a run" check in `advance_leg`
- [x] Transfer eggs blocking starter route — transfer-target encounters are excluded from route-lock checks (`encounters.py:90-96`)
- [x] Shiny flag preservation during transfers — `is_shiny` is copied to egg encounter (`genlockes.py`)
- [x] Genlocke deletion cascading properly — CASCADE on FK for both `GenlockeLeg` and `GenlockeTransfer`, runs properly unlinked
- [x] Duplicate source transfers — prevented in practice by the "next leg already has a run" guard; `target_encounter_id` has a UNIQUE constraint
- [x] Empty transfer list — valid behavior, advances leg without transfers
