Add a Predge plugin: gate workflows on a verified smart-money signal

### Before filing
- [x] I searched open and closed issues for this proposal.
- [x] I checked the docs and the current behaviour on `staging`.
- [x] This is one change, not several.

### Reason: what you cannot do today
A KeeperHub workflow cannot gate execution on a *verified* off-chain signal from Predge without an agent bridging the data in by hand. Predge (https://predge.io) serves smart-money conviction signals over x402, each carrying a detached ed25519 signature. There is no native action that fetches such a signal and proves its signature inside a workflow, so a workflow that wants to "only move value when a high-conviction, signed signal says so" has to trust an external caller to have verified it - exactly the reinterpretation risk KeeperHub removes on the execution side.

### Reason: what the workaround costs
The workaround is an agent outside KeeperHub that fetches the signal, verifies the signature, and only then calls `execute_transfer`. That splits the trust boundary: verification lives in un-audited agent code, off the KeeperHub audit trail, and every workflow author reimplements canonical-JSON + ed25519 verification. A native action makes "verified signal in" a first-class, auditable workflow input.

### Scope: what this touches, and what it does not
Touches: a new read-only plugin `plugins/predge/` with one action, Read Predge Signal - fetch a wallet's conviction signal and verify its ed25519 signature offline (WebCrypto), exposing `conviction`, `action`, `window`, a `verified` boolean and the `signer`. Adds `predge` to `plugin-allowlist.json`. Does not touch any existing plugin, response shape, schema, auth, pricing, or the execution path. No new dependency (verification uses built-in WebCrypto Ed25519). Egress is `safeFetch` behind an `assertUrlIsPublic` SSRF check, mirroring `blockscout`.

### Plan: what you propose
Mirror the `blockscout` read plugin per `plugins/CLAUDE.md`: `index.ts` / `icon.tsx` / `credentials.ts` / `test.ts` / `steps/read-signal.ts` + `steps/predge-core.ts`. Step file exports only the step fn + `_integrationType` + types; shared fetch/verify logic in `-core.ts` (no `"use step"`); step wrapped in `runPluginStep`. Optional `PREDGE_SIGNER_KEY_ID` pins a trusted signer; works against the hosted service with `requiresCredentials: false`. Implementation is up as #2476.

### Plan: alternatives you considered
- A generic HTTP action plus a separate verify node: pushes ed25519 / canonical-JSON correctness onto every workflow author and cannot be gated safely.
- Bundling verification into the execution step: couples an input concern to the transfer and breaks the one-action-per-file convention.

### Scope: compatibility
- [ ] Changes an existing response shape, status code, CLI flag, or default.
- [ ] Adds, removes, or upgrades a dependency.
- [ ] Changes database schema or requires a migration.
- [ ] Touches authentication, permissions, validation, or spend limits.
- [ ] Changes pricing, plan limits, or anything a user is charged.

The proposed implementation is already up as #2476. If reviewing or taking over, read plugins/CLAUDE.md and the existing blockscout plugin, then inspect plugins/predge/index.ts, icon.tsx, credentials.ts, test.ts, steps/read-signal.ts, and steps/predge-core.ts; done means the read-only action fetches and verifies the signal with the documented outputs and tests pass.

Written by the indexing model from the issue text.