fix(creator): raise max_history_messages + repair refresh-cache CI (#91)

* fix(creator): raise max_history_messages to 80 for polling workflows

Creator Hand's async video_generate path polls video_status every 15-20s
until completion (1-3 min typical), consuming ~5-15 turns per video
request. Combined workflows (video + TTS + music) plus normal back-and-
forth cross the kernel default of 40 messages quickly, which surfaced
in user logs as:

  WARN run_agent_loop: Trimming old messages at safe turn boundary
    agent=creator:creator-hand total_messages=41 trimming=2
  INFO run_agent_loop: prompt cache metrics for turn
    hit_ratio=0.0 creation=0 read=0

Every turn was hitting the trim cap and invalidating the prompt-cache
prefix. 80 covers ~30 polling iterations plus a comfortable pre-context
window without runaway memory growth. Other hands keep the default 40.

* ci(refresh-cache): open PR instead of pushing directly to main

Branch protection on `main` started rejecting the workflow's auto-commit
with GH006 "Changes must be made through a pull request" — see run
25632824585 on 2026-05-10 against commit 6785807 (the first push that
hit the tightened protection). Direct push is precisely what the file's
own security comment (#1) warns against ("Compromised maintainer pushes
a malicious plugins-index.json directly to main. Mitigation: GitHub
branch protection on main requires PR review"), so the fix preserves
that gate rather than working around it.

The workflow now creates a short-lived `automation/refresh-indexes-<sha>`
branch, commits the regen there, pushes, and opens a PR back to main
via `gh pr create`. Maintainers see a one-click squash-merge.

Permissions: add `pull-requests: write` to the existing `contents: write`
so `gh pr create` can be authorised through the default GITHUB_TOKEN.

The post-merge run on the index PR is a no-op (no diff under
`hands/**`, `plugins/**`, etc. between consecutive states), so no
`[skip ci]` marker is needed and no loop is possible.

Without this fix, every content PR landing on main leaves
plugins-index.json + registry-index.json stale, blocking new agents and
hands from reaching daemons until a maintainer manually regenerates.

* fix(hands): raise max_history_messages on long-workflow coordinators

Three hand coordinators have workflows that routinely exceed the kernel
default history cap on a single user turn:

- researcher (max_iterations=80) — deep web_search → web_fetch →
  summarize loops with multi-source synthesis. 80 iterations × ~4
  messages each → 200+ messages per user turn. Set to 120.
- devops    (max_iterations=60) — incident response and CI/CD fan out
  into long shell_exec chains (logs, retries, post-mortems). Set to 80.
- predictor (max_iterations=60) — long reasoning chains accumulating
  signals across many web/knowledge queries, with scheduled re-checks
  referring back. Set to 80.

Creator's existing override is rephrased "raise above the kernel
default" so the comment stays correct regardless of the order this PR
and the upstream kernel-default bump (librefang side) land in.

Other hands (lead/linkedin/reddit/clip/analytics/apitester/browser/
collector/strategist) stay on the kernel default; the upstream bump
covers them.

hands/researcher/HAND.toml

@@ -203,6 +203,12 @@ model = "default"
 max_tokens = 16384
 temperature = 0.3
 max_iterations = 80
+# Raise the history cap above the kernel default. Deep research workflows do
+# extensive web_search → web_fetch → summarize
+# loops with multi-source synthesis: 80 iterations × ~4 messages each
+# easily produces 200+ messages per user turn. 120 keeps ~1.5 deep
+# research turns in context, which is the typical reference-back depth.
+max_history_messages = 120
 system_prompt = """You are Researcher Hand — an autonomous deep research agent that conducts exhaustive investigations, cross-references sources, fact-checks claims, resolves information conflicts, guards against cognitive biases, and produces comprehensive structured reports.
 
 ## Phase 0 — Platform Detection & Context (ALWAYS DO THIS FIRST)