fix: macOS Seatbelt denyRead rules ineffective due to file-read* wildcard

[tito]

Summary

Fixes #18

• denyRead rules on macOS were completely ineffective, .env, .env.local, and all user-configured denyRead paths were readable despite deny rules in the Seatbelt profile
• Root cause: Seatbelt ignores wildcard deny operations (deny file-read*) when a specific allow (allow file-read-data) covers the same path. The deny must use the exact same operation name as the allow.
• Fix: changed deny file-read* → deny file-read-data in all read deny rules
• Added unit tests verifying generated profiles use file-read-data for denies
• Added integration tests verifying .env files and user denyRead paths are actually blocked at runtime

How i verified the Seatbelt behavior

Tested with sandbox-exec directly to isolate the semantics:

# Wildcard deny does NOT work — file is readable:
sandbox-exec -p '(version 1)(deny default)...(allow file-read-data (subpath "/"))
  (deny file-read* (literal "/path/.env"))' cat /path/.env
→ HELLO=world  (BUG: not blocked)

# Exact operation deny DOES work:
sandbox-exec -p '(version 1)(deny default)...(allow file-read-data (subpath "/"))
  (deny file-read-data (literal "/path/.env"))' cat /path/.env
→ Operation not permitted  (FIXED)

Test plan

• Unit tests: go test ./internal/sandbox/ -run "TestMacOS_DenyRead" -v
• Integration tests: go test ./internal/sandbox/ -run "TestMacOS_SeatbeltBlocksEnv|TestMacOS_SeatbeltBlocksUserDenyRead" -v
• Manual test: greywall -d -- cat .env now blocks reading .env
• make fmt && make lint