Summary

Fixes #6195. The prompt library already supports create and delete on the dashboard; the real gap the issue asks for ("删除提示词需要验证是否已经解绑所有关联的智能体或者Hands") is a delete guard: deleting a prompt version must not orphan the agent that is actively using it.

A prompt version is per-agent (its agent_id binds it to one agent; hand-role agents use the same store). The only "bound" signal is the version's is_active flag. The dashboard hid the delete button when is_active, but PromptStore::delete_version deleted unconditionally, so a direct API/SDK call could delete the active version and leave the agent's live prompt orphaned.

Changes

Backend

• crates/librefang-memory/src/prompt.rs — delete_version now SELECT is_active first and rejects an active version with LibreFangError::InvalidState; an unknown id stays an idempotent no-op DELETE. Store unit test: active delete is rejected and the row remains, inactive deletes, unknown id is a no-op.
• crates/librefang-kernel/src/kernel/handles/prompt_store.rs — stop flattening the store error to KernelOpError::Internal (500); propagate the typed error so InvalidState surfaces as 400 via the existing kernel_op_status map.

Frontend

• PromptsPage.tsx and PromptsExperimentsModal.tsx — the active version's delete button is now rendered disabled with an explanatory tooltip (instead of hidden), so the affordance and the reason are visible.
• prompts.delete_blocked_active added to en / zh / uk.
• PromptsPage.test.tsx — updated the active-version case to assert the delete is present-but-disabled, plus a new case asserting an inactive version's delete dispatches the mutation.

Verification

Frontend — locally verified:

pnpm typecheck                                  # clean
pnpm exec vitest run src/pages/PromptsPage.test.tsx   # 10 passed
pnpm build                                      # ✓

Backend — static-reviewed, CI-pending: ⚠️ local Docker verification was not possible this run (the host disk filled and the OrbStack daemon crashed, so a cold cargo build could not run). The change is type-checked by hand: the query_row(...).optional()? chain yields Option<bool>, InvalidState { current, operation } matches the variant, and the kernel handle returns the store's Result directly (KernelOpError is an alias of LibreFangError, same type). CI is the verifier — cargo test -p librefang-memory (store guard) and cargo test -p librefang-api + cargo check --workspace --lib on the lanes.

Note: the API integration harness (prompts_routes_integration.rs) uses a mock kernel with no real PromptStore, so it cannot exercise the store guard — the store unit test is the meaningful backend coverage.