Proposal: Admin moderation for published workflows (take down and restore a public workflow)

[yangzhang75]

This builds on #6242 (Report a Public Workflow), which lets admins Unpublish a reported workflow. This proposal adds the two things that report-driven flow leaves open: acting without waiting for a report, and making a take-down stick.

The gap

In #6242, an admin resolves a report by Unpublishing, which sets the workflow back to private. But that reuses the ordinary public/private toggle, so the author can immediately re-publish it — the take-down doesn't hold. And admins can only act on workflows that users have already reported; there's no way to proactively pull a workflow an admin finds themselves.

What this adds

• Direct take-down → an admin can take down any public workflow directly, without a report existing.
• Re-publish block → a take-down also records a block (a row in a small workflow_moderation(wid, blocked_by, reason, blocked_at) table). While a block exists, the author's makePublic is refused (Forbidden, with the reason), so they can't silently re-publish.
• Restore → an admin clears the block; the workflow becomes an ordinary private workflow again and the author may re-publish normally.

The block is the shared enforcement piece: #6242's report-driven Unpublish can write the same block, so both paths — report-driven and admin-initiated — produce a take-down that actually holds.

How it works

Take-down sets is_public = false and inserts a block row. The Hub queries, the public detail page, and the guest direct-link (GET /workflow/publicised/{wid}) all already gate on is_public = true, so it leaves every public surface automatically. The only new enforcement is one check in WorkflowResource.makePublic that refuses while a block row exists. Take-down never deletes anything and never touches the author's private copy or existing clones.

Authorization reuses the existing @RolesAllowed(Array("ADMIN")) + UserRoleAuthorizer, same as the other admin resources. New surface: one admin endpoint pair (e.g. PUT /admin/workflow/{wid}/block and /unblock) plus the one guard in makePublic.

Open questions

1. Should Proposal: Report a Public Workflow #6242's report-driven Unpublish also set a block? Unifying both paths on the same block is cleaner, but means a report-based unpublish also stops the author from re-publishing until an admin restores. Recommended: yes.
2. Where does direct take-down live in the UI? Proposal: Report a Public Workflow #6242 adds a Reports tab; direct take-down has no report to hang off. Options: an admin-only action inline on the Hub, or the same admin tab extended to list all public workflows (not just reported ones).
3. Restore is required for a hard block — since a block can't otherwise be lifted (even for an admin's own mistake). Agreed, or should take-down be one-shot (no block, author free to re-publish)?

Feedback welcome, and happy to fold this into #6242 if the group prefers one thread.

[chenlica]

This feature was suggested based on the experience in a few education programs using Texera deployments. Workflows created by students and instructors were left as "Public," even though the workflows are no longer needed. They make the platform harder to use by other users. Currently only the owner of each workflow can un-publish it, and admins cannot do so.

This discussion is about workflows. Later we should do something similar for datasets and possibly other resources can can be made public.