Add tests for the agent blocklist precedence over the allowlist in record_usage

[mikewheeleer]

Test the AgentBlocked gate and its precedence over the allowlist

Description

The per-agent blocklist — set_agent_blocked, is_agent_blocked, and the AgentBlocked (#17) rejection in record_usage in contracts/escrow/src/lib.rs — is uncovered by contracts/escrow/src/test.rs. The contract documents a specific precedence: a blocked agent is rejected even if also allow-listed, and the block check runs before the allowlist check. Nothing proves this ordering, which is the entire security value of the feature. This issue locks the behaviour down with focused tests.

Requirements and context

• Repository scope: Agentpay-Org/Agentpay-contracts only.
• Cover: default (no block) allows the agent; blocked agent rejected with #17; unblock restores access; is_agent_blocked round-trips.
• Cover the precedence invariant: an agent that is both allow-listed (with the allowlist enabled) and blocked is still rejected with #17 (block beats allow), and the block fires before the AgentNotAllowed (#10) path.
• Cover that a blocked agent is rejected regardless of the allowlist being enabled or disabled.
• Use #[should_panic(expected = "Error(Contract, #17)")]; test-only change unless a genuine bug surfaces.

Suggested execution

• Fork the repo and create a branch
• git checkout -b test/contracts-blocklist-precedence-tests
• Implement changes
  • Write code in: contracts/escrow/src/lib.rs — no changes expected; only touch if a bug is found.
  • Write comprehensive tests in: contracts/escrow/src/test.rs — the blocklist and precedence scenarios above.
  • Add documentation: note the covered precedence in the test module header comment.
  • Include NatSpec-style doc comments (///) on any test helpers.
  • Validate security: the block cannot be circumvented via the allowlist.
• Test and commit

Test and commit

• Run cargo fmt --all -- --check, cargo build, and cargo test.
• Cover edge cases: blocked + allow-listed, blocked + allowlist disabled, block then unblock then re-block, multiple agents with mixed status.
• Include the full cargo test output and a short security notes section in the PR description.

Example commit message

test: cover agent blocklist precedence over the allowlist

Guidelines

• Minimum 95 percent test coverage for impacted modules.
• Clear, reviewer-focused documentation.
• Timeframe: 96 hours.

Community & contribution rewards

• 💬 Join the AgentPay community on Discord for questions, reviews, and faster merges: https://discord.gg/eXvRKkgcv
• ⭐ This is a GrantFox OSS / Official Campaign task and may be rewarded. When your PR is merged you'll be prompted to rate the project — if this issue and the maintainers helped you ship, we'd be grateful for a 5-star rating. Clear questions in Discord and tidy, well-tested PRs are the fastest path to a merge and a reward.

[gloskull]

Hello, I have 4 years of experience delivering solutions for projects like this, covering backend, frontend, and smart contract development. After carefully reviewing your requirements, I have a clear understanding of the task and am confident in my ability to deliver a clean, efficient, and thoroughly tested solution on time. I prioritize code quality, maintainability, and industry best practices throughout the development process.
My PR will be submitted in under 10hours.

[GBOYEE]

Hi! Agent blocklist precedence over allowlist tests. Plan: write tests proving that a blocked agent is rejected even if their address is also on the allowlist, testing the security-critical precedence logic. Soroban auth test pattern. Ready.

[GBOYEE]

Hey! The blocklist in contracts/escrow/src/lib.rs says a blocked agent is rejected even if also on the allowlist, and the block check runs before the allowlist check — that ordering is the whole security value. But nothing in test.rs proves it. Fix: add a test that puts an agent on both the allowlist AND the blocklist, then calls record_usage — it must hit the AgentBlocked (#17) error, not get through. Also test that a blocked-only agent is rejected, an allowed-only agent passes, and neither-listed agent respects the default. This locks down the precedence guarantee.