feat(actions): JSON Schema validation, CLI validate command, and agent-facing capabilities

[skypper]

Summary

Adds offline validation tooling and machine-readable interfaces for tenderly.yaml actions configuration, making the CLI usable by both humans and AI agents.

Schema alignment with runtime

Validated the JSON Schema against actions-trigger-service (tenderly-core) and official docs to close gaps where the schema would accept configs the runtime rejects:

• Fixed PeriodicTrigger additionalProperties interaction with oneOf
• Added anyOf enforcing the minimum filter constraint (from/to/function/eventEmitted/logEmitted)
• Tightened Hex64 pattern, address/signature regex (case-insensitive for EIP-55)
• Added cron format pattern, action name validation via patternProperties
• Added parameters to FunctionValue, {exact, not} form to ParameterCondValue.string
• Made execution_type optional (defaults to sequential)

New commands

Command	Purpose
tenderly actions validate	Two-phase offline validation: JSON Schema (structure) + Go-level (semantics). No login required.
tenderly actions validate --json	Structured {valid, schema_errors, trigger_errors} output for programmatic consumption
tenderly actions capabilities	JSON manifest of CLI capabilities: commands, trigger types, runtimes, enums, embedded schema

IDE integration

• tenderly actions init now generates tenderly-schema.json and sets $schema in tenderly.yaml for automatic IDE autocomplete (VS Code, JetBrains)

Why this matters for AI agents

AI agents building web3 actions previously had to reverse-engineer valid configs from Go source code or deploy and parse failures. This PR creates a proper machine interface:

1. Discovery — tenderly actions capabilities returns all valid enums, trigger types, and the full JSON Schema in one call. An agent can generate correct configs without reading docs.
2. Feedback loop — tenderly actions validate --json provides structured errors that agents can parse and act on programmatically, enabling write-validate-fix cycles without human intervention.
3. Schema as contract — The JSON Schema serves as a machine-readable spec that any JSON Schema-aware tool can consume.

Tested on a real project

Ran both commands against a test project (7 actions with transaction triggers, event parameters, function filters, NOT conditions, int ranges):

$ tenderly actions validate --json
{"valid": true}

$ tenderly actions capabilities | jq '.trigger_types'
["periodic", "webhook", "block", "transaction", "alert"]

Test plan

• go test ./model/actions/... — 55 tests pass (24 schema tests)
• tenderly actions validate — text output on valid/invalid configs
• tenderly actions validate --json — structured JSON output, exit 0/1
• tenderly actions capabilities | jq . — valid JSON with all fields
• tenderly actions schema -o schema.json + external validator (ajv-cli) against sample configs
• Tested on real web3 actions project with 7 action specs