RBAC read-deny: deploy/runtime get-by-key tier — attach deny-checks to positive-suite chains

Follow-up to #373. The remaining ~15 get-by-key reads are deploy/runtime resources — process/decision definitions, decision-requirements, resources, forms, process-instances, user-tasks, incidents, jobs, variables, element-instances, agent-instances, batch-operations, decision-instances, audit-logs.

To deny-test these meaningfully you need a real existing instance, which for these requires deploying a BPMN/DMN model and/or running a process and waiting for the runtime entity to appear — i.e. the positive suite's deployment/execution machinery. Re-provisioning that inside the rbac global-setup would duplicate it and be slow/flaky.

Proposed approach: rather than re-provision, attach deny-checks onto the positive suite's existing entity chains — where an instance has already been created/emitted, add a step that re-fetches it as the zero-grant probe and asserts 403/404. This reuses the established instance and keeps the rbac setup lean.

Needs design (how the rbac assertion hooks into a positive chain; whether it's a new emitter mode or a chain annotation). Larger than #373.

Relates to #359, #373.

Start with #373 and the positive suite's deployment/execution machinery, then inspect how its existing entity chains emit deploy/runtime instances. Design how the RBAC assertion hooks into those chains, using an emitter mode or chain annotation, and ensure zero-grant re-fetches assert 403/404 without duplicating rbac global-setup provisioning.