[Fix] Custom automation tasks change models when another user targets them

[roomote-roomote]

​Opened on behalf of @daniel-lxs. Follow up by mentioning @roomote-roomote, in the web UI, or in Slack.

What changed

• Require user-token model-selection updates to pass the existing database-backed task access predicate before resolving or mutating the latest run.
• Preserve run-token task binding, custom-automation owner and admin access, and ordinary deployment-wide task access.
• Add real-database regression coverage for cross-user denial without persistence or sandbox restart, plus owner, admin, ordinary-task, and live-apply recovery behavior.

Why this change was made

A user token could previously target a known custom-automation task ID owned by another member and change its persisted model settings, potentially restarting its live harness. The web mutation already enforced the restrictive task-access path, but the agent-facing API only checked that some user context existed.

Impact

Unauthorized members now receive a not-found response before any run lookup, model-setting persistence, or sandbox RPC. Focused real-database coverage, the full API suite, repository type checks and lint, and the pre-push checks pass; browser proof is not applicable to this server-side authorization invariant.

[roomote-community]

No code issues found. See task

_{Reviewed 3f9f6c3}