Task graphs: authorization model for human-task assignment (assignToUser)

## Context

Deferred design item from the task-graph program plan (PR #3456), raised as **item 3 of the second review round** ([review comment](https://github.com/MemberJunction/MJ/pull/3456#issuecomment-5201514946) thread — rkihm-BC's v6 review) and explicitly deferred by @AN-BC in the same thread.

## Problem

Phase 4 of `plans/task-graph-primitive.md` introduces **human tasks as graph nodes**: an agent-emitted `TaskGraphSpec` can set `assignToUser`, creating a `MJ: Tasks` row with `UserID` set that blocks downstream agent work until the human completes it (with notification via `NotificationEngine` and DueAt escalation via the reconciliation sweep).

There is currently **no permission model** for this:

- Who may an agent-emitted graph assign blocking work to? Anyone? Only the submitting user? Role-gated?
- Can a low-privilege user's agent spawn cross-run work that lands blocking tasks (and notifications) on another user?
- How does this compose with the Unified Permissions model (`guides/UNIFIED_PERMISSIONS_GUIDE.md`) and with `MJ: AI Agent Requests` approval gates?

## Interim behavior (until this lands)

Per the plan (Phase 4 note): human tasks ship **self-assignment only** — a graph may assign human tasks to the graph's owning context user; cross-user assignment is rejected at submission validation. This keeps the hole closed without pre-empting the model designed here.

## Scope for this issue

1. Define the authorization model: who may assign to whom (self / role or permission-gated / delegation), evaluated at `TaskGraphService.Submit` validation time.
2. Integrate with Unified Permissions (a named permission for cross-user task assignment is the likely shape).
3. Decide notification/consent semantics for the assignee (silent task creation vs. accept/decline).
4. Cover the headless approval-as-human-task case (plan §5 resolved-O2), where the assignee is effectively an approver.

## References

- Plan: `plans/task-graph-primitive.md` (D5, D20, §3.4 HITL, Phase 4)
- Program plan: `plans/unified-workflow.md`
- PR: #3456

Start with plans/task-graph-primitive.md, especially D5, D20, §3.4 HITL, and Phase 4, then read guides/UNIFIED_PERMISSIONS_GUIDE.md and the TaskGraphService.Submit validation path. Done means the assignment authorization model, Unified Permissions integration, assignee consent semantics, and approval-as-human-task behavior are decided and enforced.

Written by the indexing model from the issue text.