BREG task grants: a task-grant profile compiles with approve_request and apply_request in operations

## What

An access profile with `actorKind: agent` and a `taskGrant` binding compiles cleanly when its `permissions[].operations` include `approve_request` and `apply_request`. The compiler's task-grant guard only refuses direct target mutation: `create` and `patch` on entities without change control, plus `tombstone`, `batch` and `invoke`. The review-decision operations are not in that list, so a task-grant profile can be authored with authority to approve and apply a change request it drafted.

The exclusion is real at runtime but behavioural only, so nothing tells an author at authoring time that the profile they wrote will not do what it says. A compiled artifact that claims authority the runtime will refuse is a poor contract, and the `explain` output repeats the claim.

## Evidence

- `crates/registry-breg/src/compiler.rs` around line 1641: the `direct_mutation_forbidden` predicate matches `Operation::Create | Operation::Patch => !governed_request_draft`, `Operation::Tombstone | Operation::Batch | Operation::Invoke => true`, and `_ => false`. `ApproveRequest`, `ApplyRequest`, `RejectRequest` and `RequestRevision` all fall through the `_` arm.
- `crates/registry-breg/tests/http_auth.rs` lines 537 to 548 construct exactly this case: an `actorKind: agent` profile with `taskGrant: {sourceIssuer: ...}` and `operations: [create, get, patch, submit_request, approve_request, ...]`, and the test asserts `compile_project(...).expect("governed request draft create and patch remain available")`, so the approve permission compiles too.
- The only task-grant diagnostics that exist are `access_profile.task_grant.binding_required` (line 1626), `access_profile.task_grant.invalid` (line 1636) and `access_profile.task_grant.direct_mutation_forbidden` (line 1656).

## Proposed fix

Add an `access_profile.task_grant.operation_forbidden` diagnostic that refuses `approve_request` and `apply_request` on a task-grant profile at authoring time, and decide at the same time whether `reject_request` and `request_revision` belong in the same family. `tombstone` is already covered by `direct_mutation_forbidden`. Add a refusal test beside the existing one in `crates/registry-breg/tests/http_auth.rs`.

## Found while

Extracting reusable App Kit skills against Registry Stack v0.32.0.

Start in crates/registry-breg/src/compiler.rs around the direct_mutation_forbidden predicate and review the existing task-grant diagnostics. Then inspect the related case in crates/registry-breg/tests/http_auth.rs around lines 537-548. Done means task-grant profiles refuse approve_request and apply_request with the new diagnostic, with the treatment of reject_request and request_revision decided and covered by a refusal test.

Written by the indexing model from the issue text.