Self-consistent permissions: `rea cache set` denied by REA's own permission hook (0.10.0)

[himerus]

Symptom

When push-review fails with a cache-miss, the gate's error message says:

Run: rea cache set <sha> pass --branch <x> --base <y>

Attempting to run that exact command from an agent session is DENIED by the gateway/permission hook. The deny-reason string is factually wrong — it claims no codex.review audit entry exists for the SHA, even when one was just written.

Real-world impact

During the @bookedsolid/rea@0.9.2 upgrade on bookedsolidtech/helix, Jake had to personally execute rea cache set via the ! shell prefix because every agent-initiated retry was denied. Two retries, both denied, with the same wrong reason string.

This makes the documented remediation path impossible for agents — the gate's own error message points to a command the gate then refuses to run.

Fix required

1. Default gateway middleware must allow rea cache set|get|list and rea audit record. These are REA's own governance surface; denying them breaks the gate's own remediation workflow.
2. Add a rea.* command tier that cannot be stripped by downstream policy. Consumers can tighten other middleware but must not be able to deny REA's own CLI.
3. Fix the permission hook's deny-reason string. It currently reports "no codex.review audit entry" even when the entry was written seconds earlier. Either the check is reading the wrong file, or the reason string is boilerplate copy-pasted from a different check.

Acceptance

An agent that follows the exact remediation text in a PUSH BLOCKED error message must succeed on the first retry. No manual ! intervention required.

Test:

# Simulate cache-miss with a valid codex.review audit entry
rea audit record codex-review --head-sha $SHA --verdict pass ...
rea cache set $SHA pass --branch feature/x --base dev
# → MUST succeed. Currently fails with "no codex.review audit entry".