Re-contract assignment enable/disable as a scope-shape action keyed by checker ID and target scope

Replace the assignment-UUID update action with a v2 scope-shape action built from ProcessorRegistry's scope_batch_update_ops: entity_type=idle_checker, scope_targets=[target_scope], operation=UPDATE. The scope-shape validator fixes permission resolution to the single target-scope connection; a single-entity check would OR all virtual-scope paths and leak cross-scope.

- Input contract: checker_id + scope_type + scope_id + enabled
- Service validation order: (1) checker exists, (2) (scope, checker) binding exists, (3) scope permission, (4) update binding.enabled only
- Audit: entity ref idle_checker:{id} plus scope ref in audit_log_scopes
- The result is the IdleCheckerAssignment relation type keyed by (checker, scope): not a Node and carrying no assignment UUID, per the Relations rules in src/ai/backend/manager/api/gql/AGENTS.md
- Assignment domain migration to the v2 registry is a separate prior issue

## Success Criteria
- [ ] user with UPDATE in P1: enable/disable of (P1, C1) succeeds; enabled flips, checker definition unchanged
- [ ] same user against (P2, C1) without P2 permission: NotEnoughPermission, no change
- [ ] nonexistent checker or missing binding: not-found error before the permission check
- [ ] audit row: operation UPDATE, entity idle_checker:C1, scope row (project, P1)
- [ ] the action result carries no assignment UUID
- [ ] pants test passes for affected packages

JIRA Issue: BA-7238

Read the Relations rules in src/ai/backend/manager/api/gql/AGENTS.md and trace ProcessorRegistry's scope_batch_update_ops entry point. Verify the checker, binding, permission, update, audit, and relation-result behavior against the listed success criteria, then run the pants tests for the affected packages.

Written by the indexing model from the issue text.