🐛 Fix(evaluation): surface run delete errors and hide the delete button for unauthorized users

[cj2026-bit]

Problem

1. On the evaluation page, the run-delete handler awaited fetch(DELETE /api/agent-evaluations/{id}) and then removed the row from the table without ever looking at the response. fetch only rejects on network errors, so every HTTP failure was treated as success. For a non-creator DEV user the backend answers 403 160208 ("Only the creator or a tenant administrator can delete this evaluation run"): the row vanished with no message, the run stayed in the database and "came back" after a refresh — a silent false success.
2. The same unchecked-fetch pattern existed in three more mutating calls on the page: evaluator delete (table view and card view) and evaluator publish. Those refresh the list afterwards, so a failure did not corrupt the list, but the user got no feedback at all (silent no-op).
3. Even with correct error handling, showing a delete button that can only fail is poor UX for restricted roles: the backend allows only the run creator or the admin-like roles (SU/ADMIN/SPEED/ASSET_OWNER) to delete a run.

Fix

Run delete (root cause)

• Check the DELETE response: on failure show an error toast — getI18nErrorMessage maps the backend codes (160208, 000501; the zh/en errorCode.* translations already exist) — and keep the row; remove it from the table only on success.

Button visibility

• The run delete button renders only when the current user may actually delete that run: run.created_by === user.id or the role is in SU/ADMIN/SPEED/ASSET_OWNER (mirrors the backend CAN_EDIT_ALL_USER_ROLES in consts/const.py). The list API already returns created_by and the auth context provides user.id/user.role, so no backend change was needed. While the user context is still loading the button stays hidden (fail-safe).

Evaluator delete / publish

• Same response check and error toast before refreshing the list, in both the table and the card view.
• New i18n key agentEvaluation.publishFailed (zh/en); every other message reuses existing keys and existing errorCode.* translations.

Scope

• Frontend only. No backend, API or migration change.

Verification

Local full-mode stack, frontend and backend both started from this branch:

• DEV non-creator: the runs table shows only the view button on every row (delete hidden); the list API still returns created_by, so the creator check works on real data.
• ADMIN: delete button visible; UI delete of a run returns 200, the row disappears, stays gone after refresh, and the DB row is really gone.
• Error path (the original false-success scenario): deleted a run via API, then clicked delete on the stale row in the UI → 404 000501, the toast "资源不存在" appears and the row is kept. Before the fix this exact flow removed the row silently.
• Backend permission unchanged: a direct API delete as the DEV user still returns 403 160208.
• tsc --noEmit: no new errors (the two vitest.config.ts overload errors also exist on the develop base); pre-commit hooks pass.