BREG task grants: runtime guard on the batch path and two clarity fixes

Follow-up to #1029.

- [ ] `execute_batch_after_attempt` in `crates/registry-breg/src/mutation.rs` relies only on the compile-time rule `access_profile.task_grant.direct_mutation_forbidden` to keep task profiles off the batch path. Refuse grant tokens at its start, as `execute_after_attempt` does, so a later compiler change cannot open it.
- [ ] `authenticate` in `crates/registry-breg/src/auth.rs` parses flat direct claims before discarding them for grant tokens, so a malformed flat value on a grant token gives 401 even though the value would be ignored. Skip the flat parse for grant tokens, or document the refusal.
- [ ] `products/breg/TASK_GRANTS.md`: state that `registry_request_task_authority` rows keep the disclosed subjects until erasure removes them.

Start with execute_batch_after_attempt in crates/registry-breg/src/mutation.rs and compare its entry checks with execute_after_attempt. Then inspect authenticate in crates/registry-breg/src/auth.rs and the task-grant guidance in products/breg/TASK_GRANTS.md. Done means the batch path refuses grant tokens, ignored malformed flat claims do not cause grant authentication failures, and the documentation states the disclosed-subject retention rule.

Written by the indexing model from the issue text.