feat: search_protocol_actions doesn't indicate which actions support direct execution

### Before filing
- [x] I searched open and closed issues for this proposal (checked #2004, #2097, #2207, #2398, #2206, #2205, #1869 for overlap — none cover `search_protocol_actions` discoverability).
- [x] I checked the docs and the current behaviour in production.
- [x] This is one change.

### Reason: what you cannot do today

`search_protocol_actions` returns actionTypes that look directly executable but are not. Calling one of them via `execute_protocol_action` fails with a `501`:

```
$ curl -s https://app.keeperhub.com/mcp ... tools/call execute_protocol_action \
-d '{"actionType":"tempo/transfer-with-memo","idempotency_key":"...","params":{}}'

{"error":"Direct execution not supported for \"tempo/transfer-with-memo\". Use workflow execution instead.","hint":"Create a workflow with this action and execute it via workflow_execute."}
```

Reproduced today (2026-09-15) against production for every `tempo/*` actionType (`transfer-with-memo`, `batch-payout`, `dex-swap`, `hold-payment`) and for `web3/read-contract`, `math/format-number` — all workflow-only. Meanwhile `aave-v3/supply`, `chronicle/eth-usd-read`, and other protocol integrations execute directly and succeed (confirmed with real on-chain broadcasts on Base Sepolia). `search_protocol_actions`'s response carries no field distinguishing the two classes — an agent (or a human) only finds out by calling `execute_protocol_action` and checking for a 501.

### Reason: what the workaround costs

There is no workaround short of maintaining an external allowlist of "actionTypes known to support direct execution," built by trial and error, that has to be kept in sync by hand as KeeperHub adds protocol integrations. For an agent choosing an actionType autonomously (the exact use case `search_protocol_actions` exists for), this means a real chance of picking a workflow-only action and burning a round trip on a 501 it could not have predicted.

### Scope: what this touches, and what it does not

**Touches:** `search_protocol_actions`'s response shape only — each returned action entry.

**Does not touch:** `execute_protocol_action`'s own behavior (the 501 itself is correct and should stay), `list_action_schemas`, or the workflow-execution path.

Checked and confirmed workflow-only for all four `tempo/*` actions plus `web3/read-contract` and `math/format-number`; checked and confirmed directly-executable for `aave-v3/supply` (real broadcast, confirmed) and `chronicle/eth-usd-read` (real read, confirmed). Did not exhaustively check every actionType in the catalog — the fix should be structural (read from whatever internal registry already decides the 501, since that's the source of truth) rather than a hand-maintained list, so it would not need re-checking as new integrations are added.

### Plan: what you propose

Add a boolean field (e.g. `directExecutionSupported`) to each `search_protocol_actions` result, sourced from the same registry/check that `execute_protocol_action` already uses to decide whether to return the 501. This changes no existing field and is additive to the response shape. If that registry isn't currently queryable outside the execute path, a cheaper interim fix: have `execute_protocol_action`'s 501 error include a `workflowOnly: true` field so callers can at least cache the result of one failed attempt without re-guessing on retry — worth naming as an alternative if the structural fix is bigger than it looks.

Start with the search_protocol_actions response implementation and trace how each returned action entry is assembled. Then inspect the execute_protocol_action path that produces the 501 and identify the existing registry or check used as its source of truth. Done means every search result exposes whether direct execution is supported, existing fields and execution behavior remain unchanged, and the relevant tests pass.

Written by the indexing model from the issue text.