Evals UI improvements: edit and delete

[snopoke]

• Add 'edit' & 'delete' button to evaluation details page
• Add 'delete' button to eval list view

[barry47products]

.take

[github-actions]

Thank you for looking into this issue! Please let us know if you have any questions or require any help.

[barry47products]

Hi! Taking this on as a first contribution, following the contribution guide this time.

Proposed approach:

• Add a DeleteEvaluation view following the in-app DeleteEvaluator/DeleteDataset pattern (Django DeleteView + get_queryset() for team scoping, PermissionRequiredMixin for evaluations.delete_evaluationconfig)
• Enable it via make_crud_urls(..., delete=True) in apps/evaluations/urls.py
• Add delete_action to EvaluationConfigTable for the list-table trash icon (matches every other table in the app)
• Add Edit and Delete buttons to the detail page header in evaluation_runs_home.html. The Delete URL uses ?redirect=1 so the view returns HX-Redirect to the list (the detail page no longer exists after delete). Without the query param, the list-table delete gets the normal empty-200 → HTMX inline row removal.

UX
One UX decision I'd like input on: deleting an EvaluationConfig cascades to all its EvaluationRun and EvaluationResult rows. Planning to use this hx-confirm message to make that explicit:

▎ "Delete this evaluation and all its run history? This cannot be undone."

Is that the right level of warning, or would you prefer a stronger modal / typed confirmation pattern?

Tests
One new test file with two tests — covers the only custom branch (the ?redirect=1 conditional). Matching the existing convention where DeleteEvaluator/DeleteDataset have no view tests.

Out of scope (flagging now so I don't surprise reviewers)
I noticed three things during the design pass that aren't strictly part of #3203 but came up while looking at the surrounding code. Happy to open follow-up issues for any/all of them if you think they're worth tracking — let me know which (if any) you'd like me to file:

1. Modernize evaluations DeleteViews to use form_valid() instead of the deprecated delete() override.
   Django 4.0+ soft-deprecated overriding delete() directly on DeleteView in favour of form_valid(). Affects DeleteEvaluator, DeleteDataset, and (if we follow convention) the new DeleteEvaluation. Pure refactor, no behaviour change. Keeping the new view consistent with the existing two in this PR rather than partially modernizing.
2. Guard destructive evaluation operations against in-flight runs.
   If an EvaluationRun is PROCESSING when its parent EvaluationConfig is deleted, the CASCADE wipes the run row and the Celery worker crashes on next ORM access. Same gap exists today for DeleteEvaluator and DeleteDataset. Could be solved with a UI guard, a server-side 409, or a soft-delete pattern. Probably worth scoping across all three delete views together.
3. Standardize confirmation dialog UX for destructive actions.
   The list table's delete_action renders an alertify modal (styled, matches app design); my detail-page Delete button uses HTMX's hx-confirm (native browser dialog). Both work, but they look completely different. This is really a design-system question — which pattern should win project-wide? — more than a bug. Surfaced by this PR but not caused by it.

Happy to adjust based on feedback.

[snopoke]

@barry47products thank for the approach plan. This all looks good to me including the hx-confirm option (also used elsewhere).

Regarding the out of scope items, let's open followup issues for all three.