fix: gate github_clone and github_pull behind approval

Both tools were registered with kind="read" in TOOL_DEFS, so
approval_for_tool() returned False and overrode the approval=True
set at the call site. The permission engine then classified them
as READ (requires_approval=False → RiskClass.READ), auto-allowing
them without ever prompting the user — even though both write to
disk (clone creates a new directory, pull fast-forwards an existing
repo) and their own descriptions say "Requires user approval".

The connector list API (tool_dicts) always reports
requires_approval=True, so the UI showed them as gated while the
runtime silently bypassed the gate — a mismatch that made the bug
invisible to users.

Reclassify both as kind="write" so the §36 kind→approval mapping
correctly gates them.

coworker/connectors/tool_defs.py

@@ -144,14 +144,14 @@ TOOL_DEFS: tuple[ConnectorToolDef, ...] = (
         "github",
         "github_clone",
         "Clone a repo",
-        "read",
+        "write",
         "Clone a repository into a session folder to explore the code.",
     ),
     ConnectorToolDef(
         "github",
         "github_pull",
         "Update a clone",
-        "read",
+        "write",
         "Fast-forward an existing clone to the latest commits.",
     ),
     ConnectorToolDef(

tests/test_send_target_resolution.py

@@ -36,6 +36,10 @@ def test_integration_tools_reads_are_free_writes_gate(tmp_path):
     assert (
         tools["github_create_issue"].__aisuite_tool_metadata__.requires_approval is True
     )
+    # github_clone and github_pull write to disk (clone creates a directory, pull
+    # fast-forwards an existing repo), so they must gate despite being GitHub tools.
+    assert tools["github_clone"].__aisuite_tool_metadata__.requires_approval is True
+    assert tools["github_pull"].__aisuite_tool_metadata__.requires_approval is True
 
 
 def test_browser_automation_reads_are_free_interactions_gate():