Task grants: end-to-end refusal test through production wiring

Follow-up to #1029.

Some live task grant tests build clients by hand, for example BREG's status client with `.with_audience`. A wiring defect that only real deployments hit can then pass CI: the missing status assertion audience fixed in #1029 escaped this way.

Add one end-to-end test in which Casework, ThunderID, BREG and Evidence are configured only through the maintained tooling and runtime configuration, with no hand-built clients, and an officer approves a grant for one agent and one household:

- [ ] A read of the approved household succeeds; a read of another household is refused
- [ ] The same assertion exchanged by a different registered client yields a token that BREG and Evidence refuse
- [ ] After revocation in Casework, a grant-bound BREG write is refused
- [ ] A re-exchange after `registry_grant_exp` yields a token that BREG and Evidence refuse (`crates/registry-evidence-client/tests/against_a_real_deployment.rs` already covers Evidence; reuse it)
- [ ] The test runs in CI, or its README states where it runs and why

Start with the maintained tooling and runtime configuration for Casework, ThunderID, BREG, and Evidence, then read the hand-built-client coverage described in #1029 and crates/registry-evidence-client/tests/against_a_real_deployment.rs. Build the end-to-end grant flow and verify each listed refusal case, including the post-expiry re-exchange. Done means the test runs in CI, or its README documents where and why it runs.

Written by the indexing model from the issue text.