fix(permissions): deny rules now take precedence over allowed_tools

[sridhar-3009]

Summary

Closes #313

PermissionChecker.evaluate() short-circuited to allowed=True when a
tool appeared in allowed_tools before evaluating either
path_rules deny entries or denied_commands patterns. This meant:

• A path deny rule like */etc/* had no effect for any tool listed in
  allowed_tools.
• A denied command pattern (e.g. rm -rf /) was also bypassed.

The fix moves the allowed_tools allow-check to after both deny
blocks, preserving the intended deny-wins semantics.

Before:

denied_tools → [early return False]
allowed_tools → [early return True]  ← bypassed path/command deny below
path deny rules
denied_commands

After:

denied_tools → [early return False]
path deny rules → [early return False if matched]
denied_commands → [early return False if matched]
allowed_tools → [early return True]

Test plan

• Configure allowed_tools: ["bash"] + a path deny rule for */etc/*. Verify that bash with a file path under /etc/ is still denied.
• Configure allowed_tools: ["bash"] + denied_commands: ["rm -rf *"]. Verify the command is denied even though bash is allowed.
• Verify existing allow-list behaviour (tool in allowed_tools, no conflicting deny rule) still returns allowed=True.