[feat] Platform-op catalog: decide on HTTP methods beyond GET/POST (PUT/PATCH/DELETE)

[mmabrouk]

Context

Raised by @mmabrouk while reviewing #4893 (the platform-op catalog), on PlatformOp.method:
"what about put delete and other methods" (review comment).

Current state

PlatformOp.method (sdks/python/agenta/sdk/agents/platform/op_catalog.py) and the wire field
ToolCall.method (sdks/python/agenta/sdk/agents/tools/models.py) are both
Literal["GET", "POST"]. The restriction is deliberate and documented:

method is restricted to GET / POST (the runner is a constrained dispatcher, never an
arbitrary HTTP client).

All three current ops (find_capabilities, query_workflows, commit_revision) are POST.

The ask

Decide whether to widen the allowed methods to PUT / PATCH / DELETE, or keep the
GET/POST-only constraint on purpose.

Decision points:

• Which Agenta endpoints would a platform op realistically need beyond POST? The Agenta API is
  largely RPC-over-POST today, so this may be speculative.
• Security posture: the "constrained dispatcher" framing is a deliberate guardrail. Widening the
  method set widens what a tool can do against the run's own Agenta origin.
• If we widen, the change spans: SDK PlatformOp.method, the wire ToolCall.method, the runner
  (services/agent/src/tools/direct.ts callDirect + SSRF guard), the golden wire contract, and
  the docs that currently justify GET/POST-only.

Out of scope for the merged PR; no consumer needs it yet. Tracking so the decision is explicit.

[linear-code]

AGE-3840

[mmabrouk]

Closing — DELETE was added to the method literal since this issue was filed; the remaining PUT/PATCH question isn't currently blocking anything.