[Epic] Security & RBAC hardening — make Tesks safe for untrusted tenants

Tracking epic for the security tranche that must land before the cloud API is exposed to untrusted tenants. From the 2026-06-15 backend+frontend audit, three things are broken/missing and one capability (configurable RBAC) is being expanded per product direction.

Goal

• Close cross-tenant data leakage (IDOR).
• Move RBAC enforcement server-side (API and MCP), not UI-only.
• Configurable roles per workspace (beyond the fixed enum), with sane defaults admin / contributor / viewer, plus an owner that is effectively an admin and cannot be removed/demoted by another admin.
• Stop unguarded hard-deletes.

Children

• PAR-183 — Cross-tenant IDOR: tenant scoping on by-UUID queries (urgent)
• PAR-184 — Configurable RBAC role+permission model + default role set seeding
• PAR-185 — Server-side RBAC enforcement (REST API + service layer)
• PAR-186 — RBAC enforcement in the MCP tool layer
• PAR-187 — UI RBAC alignment (delete→manage, owner/last-owner protection, roles admin screen)
• PAR-188 — Remove/guard destructive hard-delete (MCP tesks_delete_task)

Key context (from audit)

• Backend authorizes nothing today: security/ActorContext.java, api/ApiAuthFilter.java explicitly delegate policy to the UI; roles stored in tenant_member.role (V2__workspaces_and_membership.sql) as owner|member|viewer but never checked.
• IDOR: by-id paths omit tenant_id predicate — PostgresTaskSystem.java ~lines 285 (taskById), 307 (getTaskDetail), 336 (listComments), 345 (listActivity), 425/467 (updateTask), 540 (deleteTask), label writes 472-477. Contrast reorderTask/moveTask which correctly scope by tenant.
• Tenant binding already exists at the edge (TenantBearerFilter, McpAuthFilter, TenantContext) — enforcement can hook there + per-service.
• UI: lib/roles.ts fixed owner|member|viewer; delete gated by requireWorkspaceWrite (should be manage); no last-owner guard (lib/actions/members.ts).