Handle blocked organization deletion gracefully

[maebeale]

Closes #1497

What is the goal of this PR and why is this important?

• Deleting an organization with associated affiliations, event registrations, workshop logs, stories, or other related records previously produced a 500 error
• Admins were unable to understand or recover from the failure

How did you approach the change?

• OrganizationsController#destroy now uses destroy (instead of destroy!) so restrict_with_error validations from affiliations and event_registration_organizations surface as flash alerts
• Added a rescue ActiveRecord::InvalidForeignKey to catch DB-level FK constraint violations from associations not covered by dependent: (workshop_logs, reports, stories, story_ideas, community_news, monthly_reports, workshop_variations, workshop_variation_ideas, users)
• On failure, the user is redirected to the edit page with an alert explaining the blockage — this is where the delete button lives and where admins manage the associations (affiliations, etc.) that block deletion
• On success, redirect to the index (unchanged)
• Added request specs covering all three failure paths (affiliations, event registrations, workshop logs) plus assertions that the flash alert text renders on the destination page

UI Testing Checklist

• As an admin, delete an organization that has no affiliations or other associated records — should redirect to the index with a success notice
• As an admin, attempt to delete an organization with active affiliations — should redirect to the edit page with an alert
• As an admin, attempt to delete an organization with event registrations — should redirect to the edit page with an alert
• As an admin, attempt to delete an organization that has workshop logs — should redirect to the edit page with an alert

Anything else to add?

• Follows the same redirect-with-flash convention used by UsersController#destroy and the Rails scaffold
• Edit-page redirect matches this codebase's convention of placing delete buttons on edit forms