Hookify: new_text field doesn't work for Write tool

Bug Description

The new_text field in hookify rules is documented to work for both Edit and Write tools, but the implementation only checks Edit's new_string parameter, causing Write tool operations to silently bypass rules.

Documentation vs Implementation

README.md states:

**For file events:**
- `new_text`: New content being added (Edit, Write)
- `content`: File content (Write only)

But rule_engine.py (lines 239-240) does:

elif field == 'new_text' or field == 'new_string':
    return tool_input.get('new_string', '')  # Only checks Edit's field!

For Write tool, new_string doesn't exist, so new_text always returns empty string.

Impact

Any hookify rules using new_text field to check file content will silently fail to match when agents use the Write tool instead of Edit. This undermines the entire hook system for code quality enforcement.

Reproduction

# Edit tool - works correctly
echo '{"tool_name": "Edit", "tool_input": {"file_path": "test.tsx", "new_string": "<div>"}}' | \
  python3 hooks/pretooluse.py
# Returns blocking message ✓

# Write tool - fails silently
echo '{"tool_name": "Write", "tool_input": {"file_path": "test.tsx", "content": "<div>"}}' | \
  python3 hooks/pretooluse.py
# Returns {} (no match) ✗

Suggested Fix

# In core/rule_engine.py, line 239-240:
elif field == 'new_text' or field == 'new_string':
    return tool_input.get('new_string') or tool_input.get('content', '')

This mirrors the content field behavior which correctly checks both.

Workaround

Use content field instead of new_text in rules, since content already checks both content and new_string.