feat: API methods to manage worker admin users + per-dataset authorized users

Problem

Two permission surfaces in the worker are baked at startup and can't be edited live:

1. Worker admin users — set via the --admin-users CLI flag in the helm values. Changing the list requires editing values.yaml and re-rolling the worker pod. Any user added becomes admin on the whole worker (can deploy/stop apps, manage caches, scale, etc.).

2. Per-dataset authorized users — currently the data server reads access from a fixed config (or no auth at all). No way to share a single dataset with a specific external collaborator without restarting and re-templating.

The dashboard needs to do both of these on-demand, the same way it now drives set_app_scaling and clear_app_directory against a live worker.

Proposed API

Worker admin users

list_admin_users() -> List[str]
add_admin_user(user_id_or_email: str) -> List[str]
remove_admin_user(user_id_or_email: str) -> List[str]

• All three require admin permissions.
• remove_admin_user must refuse to drop the caller (so an admin can't accidentally lock themselves out) and must refuse to drop the last admin (so the worker is never left without one).
• Persist across worker pod restarts: write the live admin list to a small JSON file on a volume the worker actually has, OR ship it through the same app_data-on-proxy round-trip pattern that PR #123's scaling state uses (no extra volume needed). The startup CLI --admin-users becomes the seed; the live list overlays it.

Per-dataset authorized users

list_dataset_authorized_users(dataset_id: str) -> Dict[str, List[str]]
set_dataset_authorized_users(dataset_id: str, authorized_users: Dict[str, List[str]]) -> Dict[str, List[str]]

• Mirror the per-method authorisation shape already used by deploy_app: {"*": [...], "specific_op": [...]} so the data server can gate read vs write vs delete differently if it wants.
• Persistence: same pattern as the admin list — a small JSON file or proxy round-trip. Decision deferred to implementation.

Dashboard integration

Once the API ships, the dashboard at src/components/bioengine/ should expose:

• A "Worker settings → Admins" panel listing current admins, with add/remove inputs. Greyed-out remove button next to the current caller + the sole remaining admin.
• A per-dataset "Access" panel under the existing dataset card, mirroring the app-level authorized_users editor.

(UI work tracked separately in bioimage.io; this issue covers the worker API.)

Out of scope

• Auth tokens (Hypha already issues those).
• Group-based ACLs (the per-deployment authorized_users is per-user/email; same shape applies here for consistency).
• Editing user roles inside a Hypha workspace (that's the Hypha admin's job).

Why bundle these two

Same persistence question, same dashboard-driven pattern, same need to survive worker restarts. Shipping both in one PR lets the persistence story land once instead of getting reinvented twice.