feat(everyrow-mcp): reduce progress polling for widget-capable clients

[jackwildman]

Summary

• Replace the tight 12s polling loop with a single 25s long-poll for claude.ai and Claude Desktop, reducing tool calls from unbounded (~20+ per task) to always 3
• Add should_long_poll() detection and _progress_long_poll() with internal 5s checks, widget handoff message, and "Ask Claude to show results" widget prompt
• Increase GCPBackendPolicy timeoutSec to 120s; stdio (Claude Code) and internal clients keep the 12s loop unchanged

Context

On claude.ai, everyrow_progress is called every 12s in a tight loop. At ~20 tool calls per turn, Claude hits the limit after ~4 minutes, requiring the user to click "Continue." The MCP App widget already handles visual progress independently via REST polling, so Claude's repeated checks are redundant.

Tool call comparison:

Task duration	Current (12s loop)	New approach
< 25s	3-4 calls	3 calls
5 min	~27 calls (hits limit)	3 calls
20 min	~102 calls (hits limit 5x)	3 calls

Client behavior:

Client	Behavior	Reason
claude.ai / Claude Desktop	Single long-poll then stop	Widget handles visual, conserve tool quota
Claude Code (stdio)	12s short-poll loop (unchanged)	No turn limits, status line shows progress
everyrow-cc (internal)	12s short-poll loop (unchanged)	Browser handles visual, agent generates commentary

Test plan

• 14 new tests for should_long_poll(), progress_message(widget_handoff=True), and _progress_long_poll() (completion, timeout, intermittent errors, all-fail, progress reporting)
• 138 existing tests pass (no regressions)
• Deploy GCPBackendPolicy to staging, verify timeoutSec: 120
• Test on claude.ai with fast task (< 25s): completes in one progress call
• Test on claude.ai with long task (> 25s): single progress call then widget handoff
• Test on Claude Code (stdio): 12s polling loop unchanged
• Test on everyrow-cc: behavior unchanged

🤖 Generated with Claude Code