Broaden zapier-sdk-explorer scope beyond durable workflows

[BenMcGit]

Summary

The zapier-sdk-explorer agent was scoped exclusively to durable-workflow authoring. In practice, callers researching general SDK usage — "what actions does this app expose?", "what fields does this action take?", "which connection should I use?" — read that description and skipped the agent, reinventing read-only action discovery by hand with piped list-actions / list-action-input-fields / grep invocations. That pattern is slow, noisy, and misses the agent's grounding rules.

This change broadens the agent to cover any read-only SDK investigation, with two documented output modes:

1. Prose + cited CLI commands — the new default, for one-off questions.
2. JSON build plan — unchanged, invoked only when the caller signals durable-workflow authoring.

Grounding rules (rules 1–8), the allowed CLI surface, the investigation strategy for workflow plans, and the JSON schema itself are all unchanged. The edits are surgical: frontmatter description, opening body framing, output-format section split, and the "What you are not" paragraph.

Why now

Read-only SDK discovery is emerging as a distinct use case from durable-workflow authoring — agents and humans both increasingly want to answer "how do I use action X?" without committing to a full workflow scaffold. Keeping this agent scoped only to the workflow path leaves the discovery lane uncovered and pushes callers to grep-and-guess.

Test plan

• Verify the agent still returns the JSON contract when a caller asks for a durable-workflow build plan (existing behavior).
• Verify a one-off question like "what search actions does Slack expose?" produces a prose answer with cited CLI commands, not the JSON contract.
• Verify the grounding rules (no invented identifiers, versioned implementation_id, 20-tool-call cap, sensitive-partner list, Catch Hook special case) still fire for workflow-authoring requests.