Revert query_wiki cap in skill compile agent

The QUERY_WIKI_MAX_CALLS=3 limit added in 2b94014 was over-engineered
defence:

- It was based on a theoretical worst-case bound (80 outer turns × 50
  inner turns) from a perf review, not on observed misuse.
- There's no telemetry showing real compiles ever approach pathological
  query_wiki usage.
- The prompt's "narrow follow-ups only" guidance plus the docstring
  ("nested LLM call, prefer direct reads") are already the right
  primary control. Adding a structural hard-cap on top of that says
  "we trust the agent to make 80 reasoning steps but not to count to
  3", which is inconsistent.
- The cap had a real cost: a legitimately complex cross-document
  intent that genuinely needed a 4th query_wiki got cut off and forced
  back to direct reads, silently degrading skill quality.

Also fixes the docstring bug a reviewer flagged on 2b94014: the
docstring referenced the literal Python name `QUERY_WIKI_MAX_CALLS`
rather than the value, so the model saw a meaningless symbol. Removing
the cap removes the docstring claim too.

If runaway compiles ever show up in telemetry, prefer a logged warning
(observe-and-tune) over a silent block.

Author: KylinMountain

openkb/skill/creator.py

@@ -31,7 +31,6 @@
 from openkb.schema import get_agents_md
 
 MAX_TURNS = 80  # higher than query (50) because compile can write multiple files
-QUERY_WIKI_MAX_CALLS = 3  # bound nested-LLM tail latency; agents should prefer direct reads
 
 
 def build_skill_create_agent(
@@ -104,33 +103,18 @@ def get_image(image_path: str) -> ToolOutputImage | ToolOutputText:
             return ToolOutputImage(image_url=result["image_url"])
         return ToolOutputText(text=result["text"])
 
-    # Per-compile counter for query_wiki. Each invocation spawns a nested
-    # Runner.run(max_turns=50), so an agent that leans on this tool can
-    # blow up wall-clock and token cost. The docstring already nudges
-    # toward direct reads; this hard cap is the structural backstop.
-    query_wiki_calls = 0
-
     @function_tool
     async def query_wiki(question: str) -> str:
         """Semantic search over the wiki — narrow follow-ups only.
 
-        This is a nested LLM call. Use ONLY when you have a specific
-        sub-question that direct file reads can't easily answer (e.g. "what
-        does the book say about X across multiple chapters?"). For primary
-        traversal, use list/read/get_page_content instead — they are
-        cheaper and give you the raw text, not another LLM's summary.
-
-        Capped at ``QUERY_WIKI_MAX_CALLS`` invocations per compile.
+        This is a nested LLM call: each invocation spawns a separate
+        query agent with its own turn budget. Use ONLY when you have a
+        specific sub-question that direct file reads can't easily answer
+        (e.g. "what does the book say about X across multiple
+        chapters?"). For primary traversal, use list/read/get_page_content
+        instead — they are cheaper and give you the raw text, not
+        another LLM's summary.
         """
-        nonlocal query_wiki_calls
-        query_wiki_calls += 1
-        if query_wiki_calls > QUERY_WIKI_MAX_CALLS:
-            return (
-                f"query_wiki call cap reached "
-                f"({QUERY_WIKI_MAX_CALLS} per compile). Use direct file "
-                f"reads (read_wiki_file / get_page_content) for further "
-                f"investigation."
-            )
         # Lazy import to avoid a circular dependency at module load time.
         from openkb.agent.query import run_query
         kb_dir = Path(wiki_root).parent