* fix(knowledge_sql): match write keywords on word boundaries
The read-only guard rejected a query if any of DROP/DELETE/INSERT/UPDATE/
ALTER/CREATE/ATTACH appeared as a bare substring of the uppercased text. That
wrongly blocks valid SELECTs whose column/alias/literal merely contains one --
e.g. "deleted_at" (DELETE), "created_at" (CREATE), "updated_content" (UPDATE).
The knowledge_chunks table actually has deleted_at/created_at columns and the
store's own retrieval filters on "WHERE deleted_at IS NULL", so realistic
read queries were refused. Match on word boundaries with a compiled regex,
mirroring the sibling tool db_query.py. Add a regression test.
* fix(knowledge_sql): ignore string literals in keyword scan, broaden error handling
- Strip single-quoted literals before the forbidden-keyword scan so
SELECTs whose data merely mentions a write keyword (e.g. LIKE
'%delete%') are not rejected.
- Catch sqlite3.Error instead of only OperationalError so multi-
statement strings return a failed ToolResult instead of raising.
- Document created_at/deleted_at in the tool's schema description.
---------
Co-authored-by: Elliot Slusky <elliot@slusky.com>
